[Python-3000] Change to class construction? (original) (raw)

Phillip J. Eby pje at telecommunity.com
Mon Jul 9 18:03:28 CEST 2007

At 06:13 PM 7/9/2007 +0300, Guido van Rossum wrote:

On 7/9/07, Phillip J. Eby <pje at telecommunity.com> wrote: > At 09:03 PM 7/9/2007 +1000, Nick Coghlan wrote: > >However, I will point out that setting class attributes via locals() is > >formally undefined (it happens to work in current versions of CPython, > >but there's no guarantee that will always be the case). > > As of PEP 3115, it's no longer undefined for class statements.

Where does it say so? To be honest, I don't know where ti find Nick's claim in the reference manual.

I assume Nick is referring to:

http://www.python.org/doc/2.2/ref/execframes.html

which says it's undefined. I can't seem to find where this section went to in 2.3 and beyond, or anything that says what happens with non-dictionary objects, except:

http://docs.python.org/ref/exec.html

which makes a much stronger claim:

"The built-in functions globals() and locals() return the current global and local dictionary, respectively"

and also states that as of 2.4, exec allows the use of any mapping object as the locals. There isn't any mention of the fact that locals() may not be writable, which should probably be considered an error.

But I'm surprised that you read anything about locals() into that PEP, as it doesn't mention that function at all.

Correct -- which means that either the PEP is in error, or the semantics of locals() must be that the actual namespace in use is returned.

My reasoning: since PEP 3115 allows an arbitrary mapping object to be used, there is no way that such an object can be converted to a read-only dictionary, and the current definition (as I understand it) is that locals() returns you either the actual local namespace object, or a "dictionary representing the ... namespace" (per the reference manual).

Since PEP 3115 does not require that there be any way of converting the arbitrary mapping object into a dictionary (or even that there be any pre-defined way of reading its contents!) there is no way that locals() can fulfill its existing contract except by returning that object.

QED. Well, that's the spelled-out reasoning for my intuition, anyway. :) That doesn't mean the PEP or the specification of locals() can't change, but it seems to me that if one or the other doesn't, then modifying class-suite locals() to create class members implicitly becomes official, since the failure for it to do so would become a bug in locals(). (Since it will no longer be returning a "dictionary representing the namespace" if it doesn't return that mapping object, and can't possibly return anything else that "represents" the namespace in any meaningful way.)

More information about the Python-3000 mailing list