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

[Jeremy Hylton]

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
>