[Python-3000] Change to class construction?

[Phillip J. Eby]

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.)