"Phillip J. Eby" <pje@telecommunity.com> wrote in message news:20080612100048.7EEEA3A405F@sparrow.telecommunity.com... | 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 | seems (to me) to imply that a standard dictionary (i.e. one | supporting keys of any type) is required. (In the sense that a dict | subclass which rejects non-strings would be violating the Liskov principle.) Is this requirement a documented Python requirement (not that I found), an undocumented Python requirement, or a CPython-specific requirement (that other implementations may freely ignore)? I don't have much opinion on what the rules for __dict__ attributes should be, just that whatever they are should be documented. This include implementation-defined aspects. This will help both implementors and users who wish to write Python code rather that CPython code. If there is a consensus and BDFL pronouncement, I will make or help review suggested doc changes. tjr