[Python-3000] Change to class construction?

[Guido van Rossum]

On 7/9/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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.)

Python's specification isn't as rigid as it should be, and such a
"proof" isn't worth much, especially as the reference manual hasn't
always been updated as things changed. The use of the word "mapping"
might easily be construed as implementing abc.Mapping, and then
iteration and reading the contents would be well-defined. The
weasel-words about "a dictionary representing the namespace" are meant
to cover the situation for a function's local scope, which isn't
stored in a mapping-like object at all until you use exec() or
locals(), or a few others. We could easily change this to return a
writable mapping that's not a dict at all but a "view" on the locals
just as dict.keys() returns a view on a dict. I don't see why locals()
couldn't return the object used to represent the namespace, but I
don't see that it couldn't be some view on that object either,
depending on the details of the implementation.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)