[Python-Dev] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement
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