[Python-Dev] locals(), closures, and IronPython...

[Dino Viehland]

The lifetime issue is bad - unfortunately we have the same issue in v1.x we just don't show you the names/values.  That alone should (and hopefully will) drive us to clean this up but right now we'll only be worse in that we are explicit about keeping the dictionaries alive.

Classes are interesting for us as well... Our model is that we chain all of our dictionaries together including the classes in FunctionEnvironment's (just an optimized dictionary, usually only containing the variables used in the closure) and ultimately that chains out to the globals dictionary.  The change that exposes all of the locals is to drop the explicit list of keys in the outer scopes.  The classes dictionaries get mixed in here as well and so now when doing a fully dynamic name-lookup we need to know to skip the classes which is strange.

How would "nonlocals" be used in the method?  Wouldn't you need a new opcode which would resolve to a non-local variable or add it explicitly into the LEGB search?


-----Original Message-----
From: jhylton at gmail.com [mailto:jhylton at gmail.com] On Behalf Of Jeremy Hylton
Sent: Tuesday, March 06, 2007 4:54 AM
To: Dino Viehland
Cc: Guido van Rossum; python-dev at python.org
Subject: Re: [Python-Dev] locals(), closures, and IronPython...

On 3/5/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> Thanks Guido.  It might take some time (and someone may very well beat me to it if they care a lot) but I'll see if we can get the PEP started.

Dino,

One of the questions I was puzzling over was what locals() should
return in a class scope.  It's confusing in CPython, because the same
dictionary is used to stored names that are destined to become class
attributes and names that are used to created closures for methods
with free variables.  The implementation was causing the latter names
to show up as class attributes when you called locals().

Terry is right that lifetime of variables is a key issue.  It would
probably be bad if all the local variables of a function were kept
alive because a nested function used locals().

One idea was discussed at PyCon was having a different representation
for an environment so that it would be easier to introspect on it but
still possible to pass the environment to exec.  One possibility is
just a third dictionary--globals, locals, nonlocals.  Another
possibility is an object where you can ask about the scope of each
variable but also extract a dictionary to pass to locals.

Jeremy

>
> -----Original Message-----
> From: gvanrossum at gmail.com [mailto:gvanrossum at gmail.com] On Behalf Of Guido van Rossum
> Sent: Monday, March 05, 2007 2:14 PM
> To: Dino Viehland
> Cc: python-dev at python.org
> Subject: Re: [Python-Dev] locals(), closures, and IronPython...
>
> Jeremy Hylton has been asking questions about this too at the sprint
> after PyCon. I'm tempted to accept that the exact behavior of locals()
> is implementation-defined (IOW undefined :-) as long as it includes
> the locals defined in the current scope; whether it also includes free
> variables could be debatable. I don't know too many good use cases for
> locals() apart from "learning about the implementation" I think this
> might be okay. Though a PEP might be in order to get agreement between
> users, developers and other implementation efforts (e.g. PyPy,
> Jython).
>
> On 3/5/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> >
> >
> >
> >
> > def a():
> >
> >                 x = 4
> >
> >                 y = 2
> >
> >                 def b():
> >
> >                                 print y, locals()
> >
> >                 print locals()
> >
> >                 b()
> >
> >
> >
> > a()
> >
> >
> >
> > in CPython prints:
> >
> >
> >
> > {'y': 2, 'x': 4, 'b': <function b at 0x020726F0>}
> >
> > 2 {'y': 2}
> >
> >
> >
> > I'm wondering if it's intentional that these don't print dictionaries w/ the
> > same contents or if it's more an accident of the implementation.   In other
> > words would it be reasonable for IronPython to promote all of the locals of
> > a into b's dictionary when both a and b call locals?
> >
> >
> >
> > We currently match CPython's behavior here - at least in what we display
> > although possibly not in the lifetimes of objects.  We're considering an
> > internal change which might alter the behavior here though and end up
> > displaying all the members.
> >
> >
> >
> >
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-dev/guido%40python.org
> >
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu
>