So the issues are:
1. OrderedDict().values() does not implement __eq__. It uses object equality, which means identity. 1a. dict().values() does not implement __eq__.
2. OrderedDict().keys().__eq__ does not respect order.
I'd argue that keys() should be ordered comparisons, and values() could be. As a plus, this could be more efficient than unordered comparisons, since it's just return all(x == y for x, y in zip(self.keys(), other.keys())) instead of packing each into a set and comparing the sets. But what would be the point of comparing values views?
On the other hand, I guess dict().values().__eq__ should stay unimplemented. What would it mean? MultiSet comparison? Values in general aren't even hashable, so they can't be stuck into a hash-based set structure. Maybe explicitly make it NotImplemented.
On Thu, Dec 17, 2015 at 4:40 AM, Alexandre Figura email@example.com wrote:
I recently compared OrderedDict instances while writing unit tests, and discovered an interesting behavior. If I create two ordered dictionaries with the same keys/values in the same order, I observe that their values are not equal when I compare them.
I recently asked a question about this on Stackoverflow: http://stackoverflow.com/questions/34312674/why-values-of-an-ordereddict-are...
Moreover, another user observed that keys of ordered dictionaries are compared in an order insensitive way: http://stackoverflow.com/questions/34320600/why-does-the-ordereddict-keys-vi...
Are there any reasons for such implementation choices? As it appears disturbing for many people, would it be possible to update these behaviors?
Best Regards, Alexandre.
Python-ideas mailing list Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/