[Python-Dev] bug or a feature?

[Carl Friedrich Bolz]

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