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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Hylton Sent: Tuesday, March 06, 2007 4:54 AM To: Dino Viehland Cc: Guido van Rossum; python-dev@python.org Subject: Re: [Python-Dev] locals(), closures, and IronPython... 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
