[Python-Dev] bug or a feature?

[Terry Reedy]

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

Terry Jan Reedy