[Python-Dev] Re: closure semantics
Skip Montanaro
skip at pobox.com
Sat Oct 25 12:09:55 EDT 2003
[Alex]
Assume for the sake of argument that we could make 'scope' a reserved
word. Now, what are the tradeoffs of using a "declaration"
scope x in outer
which makes all rebidings of x act in the scope of containing function
outer (including 'def x():', 'class x:', 'import x', ...); versus an
"operator" that must be used to indicate "which x" when specifically
assigning it (no "side effect rebinding" via def &c allowed -- I think it
helps the reader of code a LOT to require specific assignment!), e.g.
scope(outer).x = 23
I don't see how either of your scope statements is really any better than
"global". If I say
global x in outer
I am declaring to the compiler that x is global to the current function, and
in particular I want you to bind x to the x which is local to the function
outer.
Maybe "global" isn't perfect, but it seems to suit the situation fairly well
and avoids a new keyword to boot.
With the "scope(outer).x = 23" notation you are mixing apples and oranges
(declaration and execution). It looks like an executable statement but it's
really a declaration to the compiler. Guido has already explained why the
binding has to occur at compile time.
The tradeoffs are:
-- we can keep thinking of Python as declaration-free and by gradually
deprecating the global statement make it more so
How do you propose to subsume the current global statement's functionality?
-- the reader of code KNOWS what's being assigned to without having
to scroll up "hundreds of lines" looking for possible declarations
As he would with an extension of the current global statement. I presume
you mean for your scope pseudo function to be used at the "point of attack",
so there would likely be less separation between the declaration and the
assignment. Of course, using your argument about redundancy against you,
would I have to use
scope(outer).x = ...
each time I wanted to change the value of x? What if I rename outer?
-- assignment to nonlocals is made less casually convenient by just the
right amount to ensure it won't be overused
I don't see this as a big problem now. In my own code I rarely use global,
and never use nested functions. I suspect that's true for most people.
Skip
More information about the Python-Dev
mailing list