[Python-Dev] Explicit Lexical Scoping (pre-PEP?)

[Phillip J. Eby]

At 10:05 AM 7/6/2006 -0500, skip at pobox.com wrote:

>     jan-python> So.. are we only thinking about implementing this outer
>     jan-python> scope assignment because there's lots of talk about it on
>     jan-python> the list, ...
>
>:-)
>
>     jan-python> ... or are there actually use cases that would become
>     jan-python> clearer if assigning to an outer scope variable was allowed?
>
>I think full lexical scoping will only be of use to people who use nested
>scopes heavily.  The more typical user will be happy to just refer to values
>in outser scopes without modifying them and rely on classes to save changed
>state across calls.  I think it's almost a YAGNI, but I'm sure others will
>disagree.

Here's the reason I think this keeps coming up, and why Guido's "just use a 
class" argument doesn't really address the actual problem that's taking place.

When you are writing some function, and you find yourself using a nested 
function because it's the closest match for something you're doing, there 
occasionally comes a point at which you realize that, gosh, you need to 
mutate something in an outer scope.  At that point, your choices are to 
either kludge it with a mutable, or to reorganize the whole thing.  Both of 
these *feel* like warts because they're making you do less-than-optimal 
things.  Your mental "flow" is disrupted because the language is forcing 
you to work around it, rather than having a way of working with it.

This is a user experience issue, not a technical one.  The fact that you 
can say, "you should've done it differently in the first place" doesn't do 
anything for your flow.  In theory, you could design cars without any 
brakes, because people could just coast to a stop if they planned well 
enough in advance.  ;-)  In practice, you need the brakes because people 
often don't discover their need to stop until much later in the process.

This is a flow issue that's specific to *incremental* development.  What 
happens is that first you refactor the code in a function to include nested 
functions.  The variable references don't change, you're just indenting 
some code.  *Then*, it later comes up that you need to rebind a variable, 
and now you have to globally change the variable to make it work as a 
mutable instead, or else you have to refactor all the variables to be 
'self.' references and put a class in somewhere.

This destroys the flow of incrementally developing whatever it is you're 
developing, and makes you stop to do excise work.  That's why being able to 
rebind a variable without redefining it is important.

In short: in *theory*, a rebinding operator or "nonlocal" declaration is 
unnecessary.  In *practice*, having one seems quite useful every time you 
wander down the path that leads to having to rewrite your code just because 
the language won't let you do that one tiny thing -- or so it feels like to 
the person who's experiencing it.