[Python-Dev] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement

Raymond Hettinger python at rcn.com
Mon Mar 2 20:20:10 CET 2009

> But you'll have to convince me,

Okay, here's one stab at it.  If it doesn't take, I give in.
ISTM, either way is right depending on your point of view and what
you're trying do at the time.  My judgment tips in favor of not
specializing the __eq__ method.  But it is not lost on me why
one might think that something that iterates in a specified order
would also make an order sensitive comparison.

> Liskov cares about the signature, not about the computed value.

That wasn't my understanding.  I thought it was entirely about computed values, "Let q(x) be a property provable about objects x of 
type T. Then q(y) should be true for objects y of type S where S is a subtype of T."  Or phrased differently, "In class hierarchies, 
it should be possible to treat a specialized object as if it were a base class object."

In this case, Armin wants to be able to pass in an ordered dictionary to functions that weren't designed with ordered dicts in mind 
(config parser, json/yaml parsers, nose, unittest, etc.).  Those functions should be able to assume that all the usual dictionary 
properties are still true.  In particular, those functions may make internal comparisons to a regular dict (perhaps as a cached 
value) and would expect those comparisons to succeed.

 > I would propose the following formal specification for odict.__eq__:
>   def __eq__(self, other):
>       if not isinstance(other, odict):
>           return NotImplemented  # Give other a chance; defaults to False
>       return list(self.items()) == list(other.items())

If I haven't convinced you, then I would be happy to put this in.

>> Outside of your differing judgment on the __eq__ method, are you
>> basically happy with the ordered dict PEP?

> I am.

Once you've decided on __eq__, can I mark the PEP as approved?


More information about the Python-Dev mailing list