Confessions of a Python fanboy

[Masklinn]

On 30 Jul 2009, at 23:52 , Jan Kaliszewski wrote:
> Dnia 30-07-2009 o 22:41:57 Masklinn <masklinn at masklinn.net>  
> napisał(a):
> On 30 Jul 2009, at 22:23 , Jan Kaliszewski wrote:
>>> 30-07-2009 o 13:36:49 Masklinn <masklinn at masklinn.net> wrote:
>>>> On 30 Jul 2009, at 06:04 , alex23 wrote:
>>>>> On Jul 30, 1:06 pm, r <rt8... at gmail.com> wrote:
>>>>>> 2.) the .each method
>>>>>> container.each{|localVar| block}
>>>>>> This method can really cleanup some ugly for loops, although i  
>>>>>> really
>>>>>> like the readability of for loops.
>>>>>
>>>>> map(lambda localVar: <block>, sequence)
>>>>>
>>>>> or:
>>>>>
>>>>> def usefully_named_func(var):
>>>>>  <block>
>>>>>  return var
>>>>>
>>>>> transformed = [usefully_named_func(v) for v in sequence]
>>>>>
>>>> The issue here is of course that `map` and comprehensions are  
>>>> transformations. `#each` exists for effectful iterations (Ruby  
>>>> has `#map` for the map operation). So the intent expressed by  
>>>> `#each` and `map` isn't the same. Furthermore and this is the  
>>>> most problematic limitation of Python here, `lambda` doesn't  
>>>> allow complex transformations due to its restrictions, so one has  
>>>> to switch to named functions which works but isn't sexy (and  
>>>> tends to lower readability imo).
>>>
>>> I don't see any real limitation. What's wrong in:
>>>
>>> for localVar in container:
>>>   block
>>>
>> Well what's wrong with using that rather than `map`, `filter` or a  
>> list comprehension? (and if you don't see what the limitations of  
>> `lambda` are, you probably very rarely use it)
>
> I know well about the expression-only-limitation of lambda, fortnately
> there is the 'for' loop construct (or, alternatively, you can define
> a named function).
>
> And then, what's wrong with using 'for' rather than 'map', 'filter'  
> etc.?
Nothing, but then again nothing's wrong using C's for either.

But I do think that using higher-order functions:
* tends to be terser while not going overly terse, it only removes  
boilerplate
* is more composable (it's pretty easy to tack another transformer in  
your chain, the same way defining iterator/generator transformers and  
chaining them is simpler than doing the same thing using explicit  
`for…in`)
* it clearly spells the intent of the programmer, while `for` can be  
anything and everything, and one has to dive into the code to know  
even the high-level operations performed (is it a basic  
transformation? A filtering or partitioning? A reduction? An  
application of side effects?)
> Agree, that 'anonymous block syntax' would be nice in some cases, but
> I don't see any real limitation caused by lack of it i.e. something  
> you
> can't (all you can only with unreasonable effort).
>
There are no limitations, but once again there never are. There are no  
actual limitations to using conditional jumps over iterators either.

>>> And ruby's container.each is very similar to Python's iter()
>
>> Uh… not at all…
>
> OK, .each is like Python's iter() + some form of iterating over it
> ('for' loop or '[i]map'...).
Well of course Enumerable#each is similar to map/imap, it's the same  
core principle.