[Antoine Pitrou] > Given you were bitten by it in your own unit tests (the "eval(repr()) does not > maintain ordering" problem pointed by Georg), Completely unrelated. The original test passed because the arbitrarily ordered data in the regular dict happened to match the order added in a regular dict because I didn't shuffle the keys. There was no direct dict-to-ordered dictcomparison. Had the __eq__ method been defined differently, the test still would have passed (had a false positive). > I think it would be better to > reconsider the current __eq__ behaviour, and make it ordering-aware. If someone wants to explicitly ask for an order-sensitive comparison, the docs give a clear, simple example of how to do that. Otherwise, it's best to leave regular dict equality in-place because OrderedDicts need to be substitutable anywhere dicts are used and some of those places may make the assumption that order insensitive compares are being used. Also, the PEP outlines another issue with trying to make comparisons order sensitive. It leads to weirdness with ordereddict-to-dict comparisons making a behavior shift based on the type of one of the two inputs. It's just asking for problems and it introduces an unnecessary difference from regular dicts. Given that either choice will be surprising to someone, we opted for the simplest API with the fewest special cases and made sure the choice was clearly noted in the docs. 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