At 01:34 PM 6/12/2008 +0200, Carl Friedrich Bolz wrote:
Phillip J. Eby wrote:
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:
Which is why I said "most" - to exclude types, and objects that don't have a __dict__ slot to begin with.
I think there are good arguments for not allowing strings keys in type dicts, or at least leaving it up to the implementation.
That may well be, but there is nothing in Python's spec that I'm aware of that *forbids* it. For example the type() constructor doc doesn't say anything about using string-only keys in the class dictionary.
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.
Really? Why? Having non-string dict keys is NOT the same thing as having non-string attribute names, so attribute name lookups should be unaffected. (Attribute names *are* required to be strings, and -- as far as I know -- always have been.)