[Python-3000] Specializing the dicts in __dict__

[Ian Bicking]

Guido van Rossum wrote:
>>The suggested order would be by key creation so that reassigning
>>a key after manipulation would maintain the original order as in
>>the Thing.b case above.
> 
> 
> Unfortunately I don't think you can implement this without
> significantly slowing things down. This belief is in part based on my
> own prototype and the ordereddict implementations I found through a
> bit of searching on Google; in part because if such an algorithm
> existed (i.e. an ordered dict faster than hashing) it would be very
> popular -- but I've never heard of one.
> 
> So I'm against making the class dict an ordereddict by default (but
> I'd be for making it a symdict if we can implement one that's faster
> than a plain dict). Instead, I'd focus on changing the way the class
> statement works so that the metaclass can provide the dict object to
> be used for the local namespace in the class body. The API might be
> something like a class method on 'type' that takes some metadata like
> the proposed class name and the tuple of base classes, and returns a
> dict or a dict-ish object. The default implementation on 'type' could
> ignore the arguments and return a fresh symdict instance (or a dict
> instance if we find we can't implement a faster symdict).

I assume that means the metaclass wouldn't just be defined by 
__dict__['__metaclass__'], since that's only determined after the body 
of the class has been evaluated, and any custom dict for the namespace 
has to be determined earlier.

If type(name, bases, dict) coerced the dict object into a Real Dict 
Object, that would still give metaclasses the power to determine order, 
without having to effect the actual performance of the class.  It would 
be up to metaclasses to save information they were interested in.

Some ordered dict classes just do that for you, I think -- they have an 
underlying dict (with normal dict performance), plus they keep track of 
the order of the keys.  There's more memory used, but __getitem__ 
performance needn't be substantially effected.  (Any setting of keys has 
to be tracked, so there's a minor performance penalty.)

The potential for this performance characteristic is perhaps what 
distinguishes an ordered dict from an ordered multidict, which can't be 
implemented with just an underlying dict.

> PS: if this change to the class statement were to happen, the crowd
> discussing the 'make' PEP (which I don't like but don't have the power
> to stop being discussed) should take notice. Or perhaps they could run
> with the idea and make it the focal point of their proposal. Or
> whatever. :-)

A custom dict (working like how you describe) was proposed for 'make', 
though I think it was kind of passed over because it was too big a 
departure from the class statement.  If the class statement allowed for 
custom dicts -- or I suppose even if the idea got an approving nod -- 
then certainly the idea makes sense there.  In the context of the 'make' 
statement, dicts beyond just ordered dicts have some potential utility 
(though also a strong clever hack potential); in the context of classes 
I don't really see use cases beyond ordering.  Unless some more powerful 
class statement was used in lieu of the make statement, and all sorts of 
non-class-definitions were kludged into that syntax.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org