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

Carl Friedrich Bolz cfbolz at gmx.de
Thu Jun 12 14:56:46 CEST 2008

Phillip J. Eby wrote:

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.

Sorry, I thought we were mostly discussing type dictionaries at the moment.

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.

Fine, but as far as I can see there is also nothing that mandates it.

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

Of course attribute name lookups are affected, because you can have a non-string key that has a hash and eq method to make it look sufficiently like a string to the dict. Then the attribute lookup needs to take these into account. This makes a method cache implementation much more complex, because suddenly arbitrary user code can run during the lookup and your classes (and thus your method caches) can change under your feed during the lookup. In this situation getting the corner cases right is very hard.

Cheers,

Carl Friedrich

More information about the Python-Dev mailing list