[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[I'm a bit behind on this thread. No messages on the list for months,
then I go on a one-week vacation and receive 250 messages. :-)]
>>>>> "PP" == Paul Prescod <email@example.com> writes:
PP> Avi Bryant wrote:
>> Just to clarify - what I think you mean is that anything that can
>> be done with *Python's limited form of lambda* can be done
>> without it, since inner functions have the same restrictions
>> lambda does.
PP> Inner functions have less restrictions than lambda, but the
PP> particular restriction about overwriting variables from outer
PP> scopes is still in effect. I still maintain that this encourages
PP> a better (OO, in an OO programming language) style of
PP> programming. It seems strange to me that it is hard to get
PP> people to agree that Python's choice might just be better for
PP> Python programmers.
It's not at all clear to me that Python's current semantics are better
than a variant that allowed rebinding of names in enclosing scopes.
The PEP [a PEP is roughly equivalent to a SRFI] describing nested
There are technical issues that make it difficult to support
rebinding of names in enclosing scopes, but the primary reason
that it is not allowed in the current proposal is that Guido is
opposed to it. His motivation: it is difficult to support,
because it would require a new mechanism that would allow the
programmer to specify that an assignment in a block is supposed to
rebind the name in an enclosing block; presumably a keyword or
special syntax (x := 3) would make this possible. Given that this
would encourage the use of local variables to hold state that is
better stored in a class instance, it's not worth adding new
syntax to make this possible (in Guido's opinion).
There are a bunch of subtle interactions that make PG's example hard
to code in Python. The lack of declarations other than the global
statement make it impossible to specify where an assignment should be
to a local or to a free variable bound in an enclosing scope. I
had hoped to solve this problem when I implemented nested scopes, but
there wasn't time and Guido disagreed on its utility.
Before Python had nested lexical scopes, there was a lot of
disagreement about whether it was a useful feature. Now that they are
supported, the overall reaction seems favorable; certainly my
co-workers use them a lot. I can't help but think that full support,
including rebiding, would have played out much the same way.
The dichotomy between expressions and statements is equally
troublesome. There's no obvious way to substitute a statement for an
expression or include a statement within an expression. This is a
problem for the accumulator example, this is the problem; assignment
is a statement and lambda is an expression.