> 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? Raymond
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4