[Python-Dev] bug or a feature?

[Terry Reedy]

"Maciej Fijalkowski" <fijall at gmail.com> wrote in message 
news:693bc9ab0806111759k14f7e672r1ebd20a85d4d5af5 at mail.gmail.com...
| On Thu, Jun 12, 2008 at 2:32 AM, Terry Reedy <tjreedy at udel.edu> wrote:
| >
| > "Scott Dial" <scott+python-dev at scottdial.com> wrote in message
| > news:4850263A.3040805 at scottdial.com...
| > || If non-string keys are not allowed in __dict__, then the AddOns 
library
| > | should be changed to add another dict to the object of interest to 
track
| > | these AddOn instances.
| >
| > There are three possibilities with respect to __dict__ and non-string 
keys.
| > 1. All implementations must reject such.
| > 2. Each implementation decides for itself.
| > 3. All implementations must allow such.
| >
| > Current, CPython does not reject, eliminating 1).  Since, as I 
understand
| > it, at least 1 other implementation does reject, 3) is also eliminated
| > until Guido decrees otherwise and such implementation(s) change.  This
| > leaves 2) as the de facto situation, but this could be made clearer in 
the
| > docs: "The result of trying to add non-string keys to any __dict__
| > attribute is implementation defined."  This means that portable Python 
code
| > must act as if 1) were the case.
| >
| > The Data Model chapter of the Reference Manual lists .__dict__ as a 
special
| > attribute of callables, modules, classes, and instances.  It describes
| > __dict__ as a "namespace dictionary" or "implementation of the 
namespace"
| > thereof.  Since namespaces map names (or possibly non-name strings) to
| > objects, this to me implies that an implementation is and should not be
| > required to allow non-strings in __dict__.
| >
| > The same chapter has more than one sentence saying something like "o.x 
is
| > equivalent to o.__dict__['x']".  While one could read this as 
prohibiting
| > o.__dict__[non_string], one could also read it as being silent, neither
| > allowing nor prohibiting.
| >
| > The builtin interface functions setattr, hasattr, getattr all require
| > strings for accessing the underlying __dict__.  Since they could have 
been
| > defined otherwise, to accept any object as an attribute 'name' (key), 
this
| > again implies (to me) that __dict__s are only intended and only 
required to
| > have string keys.  Hence, I was initially surprised that 1) above was 
not
| > true.  So I might add something stronger to the docs, something like 
"The
| > special __dict__ attributes are only intended to hold string keys.  If 
an
| > implementation allows other keys, that is only an current accidental
| > side-effect of considerations of parsimony and efficiency."
| >
| > Contrariwise, if 3) were mandated, then I would think that the xxxattr
| > functions should be changed.

| This is completely irrelevant. This post is not about assigning
| non-string stuff to __dict__ of class which works completely fine.

My apologies for clipping too much of Scott's post.  Here is the rest that 
came before what I quoted, which makes clear, from first sentence to last 
line, that *he* *is* talking about assigning non-string stuff to __dict__ 
of a class.

"The AddOns library uses class objects as keys in
the __dict__, but that doesn't says anything about the usage of
locals(). At no point in the AddOns library is locals() abused like
this, so even if one asserts that assignment to the dict returned by
locals() is a bug, the underlying behavior of interest is whether
__dict__ is allowed to have non-string keys.

 >>> from peak.util.addons import AddOn
 >>> class C: pass
 >>> class A(AddOn): pass
 >>> spam = C()
 >>> print spam.__dict__
{}
 >>> A(spam)
 >>> print spam.__dict__
{<class 'A'>: <A object at ...>}
"

Whether non-strings keys in o.__dict__ 'works fine' depends on one's 
definition of 'works fine'.  In any case, as of 3.0a5, I thinks the docs 
could better clarify the status of *this* 'feature'.  Whatever 
pronouncement Guido has made has not, that I could find, made it in.

| It's about abusing locals, which are not even given that they'll
| modify this dict.

I thought it settled that that is a bad thing to do.  Here the doc is 
pretty clear.

tjr