[Python-Dev] bug or a feature?

[Carl Friedrich Bolz]

Phillip J. Eby wrote:
> At 08:32 PM 6/11/2008 -0400, Terry Reedy wrote:
>> 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.
> 
> As it happens, most objects' __dict__ slots are settable by default, and
> *require* that you set it to a dict or subclass thereof.

This is wrong for types:

$ python
Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object): pass
...
>>> A.__dict__ = {}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: attribute '__dict__' of 'type' objects is not writable

In fact it seems to me that there is no way to set non-string keys into
a type dict after class creation: Cls.__dict__ supports no setitem,
setattr checks for a string argument.

I think there are good arguments for not allowing strings keys in type
dicts, or at least leaving it up to the implementation. Using non-string
keys in type dicts is relatively awkward and allowing them makes many
interesting optimizations (like method caches) a _lot_ harder to get right.

Cheers,

Carl Friedrich Bolz