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

[Phillip J. Eby]

At 01:00 AM 7/7/2006 +0200, Jan Kanis wrote:
>On Thu, 06 Jul 2006 18:28:12 +0200, Phillip J. Eby <pje at telecommunity.com>
>wrote:
>
>>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.
>
>I agree this argument is not generally applicable in every case, but why
>not in this specific situation?

I'm saying that "just use a class" doesn't help in the incremental 
case.  If you happen to know *ahead of time* that you will need a callback 
to modify state, you can perhaps do this, just like you can always coast 
your car to a stop if you have enough advance notice.  However, sometimes 
you really want to have brakes.  :)


>>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 -
>
>I think this argument is a too general one. To me it is too close to
>"let's add every possible feature we can find, because it might be usefull
>to someone" :)

Not at all.  It's an argument regarding the incremental evolution of 
code.  Python tries to keep the growth of complexity in a code base 
relatively flat -- incremental effort should be rewarded with incremental 
benefit.  Discontinuities of complexity are to be avoided.

The classic example is "Hello world", where in Java you must learn about 
six or eight different things, but in Python it is just 'print "Hello 
world"'.  If you want to then make it a function, you indent it and add a 
'def'.  It is all very minimal and incremental, and for the most part, the 
things that people want to add to Python tend to be wherever 
discontinuities can occur.

It is also true that, because Python is already so well-designed, that 
these remaining feature areas tend to lean toward the minor and/or obscure: 
coroutines, conditional expressions, etc. etc.


>One of the things I like about python is that it doesn't do this, and
>therefore the manual stays relatively small and I don't have to remember
>all kinds of rarely used features to make best use of the language. (I
>assume this is not a point of debate. repeating: Python is not Lisp ;-) )

And one of the things that makes it not Lisp is that not everyone is free 
to go around and actually add the new syntax to support their use 
cases.  Guido must first be convinced.  Discussions like this one are how 
we convince him.  ;)


>>- or so it feels like to the person who's experiencing it.
>
>Have you ever been that person, or come across such a situation?

Many times.  The hard thing about trying to provide use cases for this is 
that of course you can always find another way to write it.  It's just that 
sometimes the nested function is a perfect solution at point in time A, and 
then at point in time B, a change in the program requires that the nested 
function mutate a bit of state, resulting in either a rewrite to do it the 
"right" way, or hacking mutable objects.

Both are user-experience discontinuities: a sudden sharp rise in effort 
compared to reward.  This then produces the perception of a "wart".  Yes, 
it's purely a superficial problem.  That's why it's called a "wart".  :)


>O, and I don't think the inc() example is a good one. In this incrementer
>the function call is all about the side effects, it's even in the name
>'increment'. Incrementing is useless unless you increment /something/, so
>this should be better implemented as a class.

Any example that's intended to motivate lexical scope modification is going 
to suffer from either being bogus due to oversimplification, or confusing 
due to application-specificity.  That doesn't make it something that 
doesn't happen, it's just that the circumstances of it happening are 
somewhat more organic.

By the way, I'm leaving out the people who have backgrounds in Lisp or 
Scheme and are trying to write it in Python.  I don't really care for Lisp, 
myself, although my Python has become increasingly functional over 
time.  Not because of Lisp (which I've never used apart from a few Emacs 
hacks 12 years ago, when I didn't even know what functional programming 
*was*), but because it's often the easiest way to do something.  At least, 
until you bump into the rebinding problem.

Personally, the idea to use a simple namespace object to store mutable 
variables as attributes seems rather appealing as a workaround solution in 
the absence of a rebinding operator.  The other solution I thought of was 
providing a function called 'rebind()' that could be used like this:

      rebind(x=23)

to change 'x' in the nearest enclosing scope.  This solves the problem 
without adding any syntax, and it's incremental at the point of use.