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.)
_______________________________________________
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
