Something is rotten in Denmark...

[harrismh777]

Terry Reedy wrote:
>> function (I know, not so) is built-in. There is little to nothing
>> indicating in the docs that this is not so
>
> On the contrary, the docs very explicitly say that a lambda expression
> is equivalent to a def statement.

Allow me to clarify... I'm not speaking about whether the lambda is 
short-hand for def, ... that part of the docs I understand well!... no 
problems there.

The part that I don't see much about in the docs (some books, that is) 
is that the lambda lookups occur late (the lambda is evaluated at the 
time it is called). The Python docs on-line *do say* this (I found too 
late) but its one quick phrase that can be missed. So, the i in 
range(10) is sitting there at '9' by the time *any* of the ten lambdas 
get called. This is not intuitive, nor good. IMHO

Please allow me to whine a little bit, ... but the *whole point* of 
iterating is to be able to implicitly grab each iterated value as it 
flies by (by the lambda or anything else!) and there is not much point 
to having a 'late-binding' on an iterable particularly range(n).

Yes, I can explicitly grab each 'i' as it flies by with a little clever 
coding of the default value for the  lambda n, i=i: i + n  but that 
'trick' is not intuitive, nor is it clear reading. It 'works' is just 
about all one can say for it (not very elegant).

I'm not sure what the answer is, but I think all of us need to think 
through it some more. Placing lambdas in a list comprehension is just 
delicious, except for the explicit kludges we have to code to get it to 
work. I'm wondering if whether it would make some sense to put some 
'binding smarts' into the interpreter to allow for 'interpreter 
intuition' (say AI ) that would presume to understand when early vs late 
binding makes sense and apply early binding in those cases where the 
context is not ambiguous and when it is clear that an iterable is being 
passed to the constant lambda function??


kind regards,
m harris