Update to PEP 227 (static scoping)
Marcin 'Qrczak' Kowalczyk
qrczak at knm.org.pl
Fri Feb 23 00:34:32 CET 2001
Thu, 22 Feb 2001 11:30:44 -0800, Russell E. Owen <owen at astrono.junkwashington.emu> pisze:
> I confess to being nervous about this proposed change.
I am very happy about static scoping. It's very natural and found in
> - complexity (the new rules have some tricky exceptions)
For me these are those exceptions which should be changed.
But I can live with them.
> - safety (Tim's example is a good one; also typos can do more damage)
It breaks only poorly written code, which relies on the fact that
a scope has holes for nested functions. Shadowing a global name and
then accessing it from inside of the function which shadowed it is
a questionable practice.
Typos don't do *more* damage. Only different typos do different damage.
With old rules wrapping a piece of code in a function silently changes
the meaning of its free variables which are not global.
> So...perhaps one could improve the syntax for lambda functions,
> instead of messing with scoping? Here is one possibility:
> lambda list-of-args : list-of-non-local-variables : code
I would not call this an improvement. It's easy to forget a variable,
in which case I silently get a legal but incorrect code. Variables
are already present in the expression, no need to repeat them.
> It would be nice if it was an error to try to refer to non-local
> variables as arguments when calling lambda, but this is by no
> means necessary.
In this case a translation between the new scheme and your scheme is
fully automatic, and the new scheme has a simpler syntax.
> How about requiring an explicit statement that "this variable
> is non-local"?
The same arguments as for lambda above apply here.
It would make sense if it allowed rebinding that variable from inner
functions. It's unnecessary when we only refer to the variable,
because there is no other choice than being non-local if it's not
assigned to here.
> If it is not deemed desirable to require declaring non-local variables,
> then I do have a final plea: some *optional* means of explicitly
> declaring a variable as local.
It's already there:
variable = None
> Optional explicit declaration also enables the ability to warn of
> the use of non-declared variables. Something that can be very nice
> for large projects -- since it catches typos.
Python already could warn about use of variables which are not defined,
except that it does not work with dynamic binding: from module import *,
exec, and modifying globals().
__("< Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
^^ SYGNATURA ZASTĘPCZA
More information about the Python-list