On Sun, May 12, 2013 at 10:01 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Fri, 03 May 2013 12:43:41 +1000 > Steven D'Aprano <st...@pearwood.info> wrote: >> On 03/05/13 11:29, Nick Coghlan wrote: >> > An exchange in one of the enum threads prompted me to write down >> > something I've occasionally thought about regarding locals(): it is >> > currently severely underspecified, and I'd like to make the current >> > CPython behaviour part of the language/library specification. (We >> > recently found a bug in the interaction between the __prepare__ method >> > and lexical closures that was indirectly related to this >> > underspecification) >> >> Fixing the underspecification is good. Enshrining a limitation as the >> one correct way, not so good. > > I have to say, I agree with Steven here. Mutating locals() is currently > an implementation detail, and it should IMHO stay that way. Only > reading a non-mutated locals() should be well-defined.
At global and class scope (and, equivalently, in exec), I strongly disagree. There, locals() is (or should be) well defined, either as identical to globals(), as the value returned from __prepare__() (and will be passed to the metaclass as the namespace). The exec case corresponds to those two instances, depending on whether the single namespace or dual namespace version is performed. What Steven was objecting to was my suggestion that CPython's current behaviour where mutating locals() may not change the local namespace be elevated to an actual requirement where mutating locals *must not* change the local namespace. He felt that was overspecifying a CPython-specific limitation, and I think he's right - at function scope, the best we can say is that modifying the result of locals() may or may not make those changes visible to other code in that function (or closures that reference the local variables in that function). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
