Python's simplicity philosophy

[Alex Martelli]

Terry Reedy wrote:

> "Alex Martelli" <aleax at aleax.it> wrote in message
> news:8Y7tb.21901$9_.802189 at news1.tin.it...
>> Dave Brueck wrote:
>>    ...
>> >> results = [ func(x) for x in sequence ]
>> >> ... instead of ...
>> >> results = sequence.map(func) ??
> 
>> > Because I find the first much more readable>
> 
>> I entirely agree with both points.
> 
> For this pair, I like the second better.  Different aesthetics.

I guess.  I just can't imagine EVERY iterable automagically
growing a 'map' method without feelign shudders of terror at
the total ugliness and gratuitous "blackmagicness" of the idea.


>>  They're even clearer when the  contrast is between, e.g.:
>> results = [ x+23 for x in sequence ]
>> and:
>> results = sequence.map(lambda x: x+23)
>> where using the HOF approach forces you
>>to understand (and read) lambda too.
> 
> Here I might take the first.  'lambda' is something I feed 'stuck'
> with.

I cherish being able to use the same construct, list comprehension,
whether I already have a callable ready or not.


> Would the hypothetical
> results = sequence.map(func x: x+23)
> be any better?

Just replacing the keyword 'lambda' with 'func'?  If you were
designing a green-field language, and couldn't find any other way
to express callable literals -- so it only came down to a 2-way
choice between lambda and func as keywords with the same semantics,
I guess I would suggest func as the lesser evil.

> How about a very hypothetical (post ``==repr deprecation)
> results = sequence..map(`x+23`)

How would this notation imply that x is an argument rather than,
say, a global?


Alex