Q: Python 2.0 preliminary features?

[Guido van Rossum]

(I'm falling into the middle again.  But this is interesting.  I hope
I haven't misunderstood Greg's description.)

Greg Ewing <greg.ewing at compaq.com> writes:
> Under my scheme, that piece of code in itself does not create
> a cycle. This is because a nested def does not immediately create
> a closure; instead it creates a special "local function object"
> which simply wraps the function. A closure is created "on
> demand" whenever a local function object is fetched out of a
> local variable. This is analogous to the way a bound method
> object is created whenever a function is fetched out of a
> class during an attribute lookup.

Hm.  I don't find it analogous, and while I agree that it's a clever
hack to avoid cycles, I don't like it much.  Here's my reason:

I dislike defining object types with "magic" properties that are
effectuated whenever they are loaded.  The magic may easily be
triggered at the wrong moment -- e.g. the debugger may be looking at
your stack frame, and depending on whether it copies the object it
pulls out of your stack frame into a local variable before looking at
it or not, it will see either a function or the magic object.  (It
doesn't have to be the debugger -- it could be any code looking at
locals()).

This is different from the method lookup -- that is only done in a
very specific context (when during attribute lookup on an instance the
object is found in the class).

Note that this is also one of the reasons why I'm feeling uneasy with
the stackless Python patch set (another reason is that it can't be
done in JPython so it can't be made a part of the language standard):
as far as I recall, it uses a magic object which when returned signals 
the interpreter to execute some callback that the called function
wanted to be executed (this is necessary for apply() I believe).

--Guido van Rossum (home page: http://www.python.org/~guido/)