On 3/5/07, Dino Viehland <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido van > Rossum > Sent: Monday, March 05, 2007 2:14 PM > To: Dino Viehland > Cc: python-dev@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 <[EMAIL PROTECTED]> 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@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@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
