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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com