[Python-Dev] bug or a feature? (original) (raw)

Carl Friedrich Bolz cfbolz at gmx.de
Thu Jun 12 13:34:44 CEST 2008

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[nonstring], 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 "", line 1, in 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

More information about the Python-Dev mailing list