Raymond Hettinger <python <at> rcn.com> writes: > 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.
Well, I may be mistaken, but it seems your test_copying (in od5.diff) still fails to check that ordering is preserved after a copy. Unless it's not part of the contract, but then the datatype would really be ill-designed IMO. > If someone wants to explicitly ask for an order-sensitive comparison, > the docs give a clear, simple example of how to do that. That's not the point. The point is that it's not enabled by default, which is rather awkward since the whole point of the OrderedDict is that it is ordering-sensitive. Right now, equality of ordering-sensitive datatypes (e.g. list) is ordering-sensitive by default. And equality of ordering-insensitive datatypes (e.g. set) is ordering-insensitive by default. > 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. You seem to imply that it is more important for __eq__ to work intuitively between a non-OrderedDict and an OrderedDict, than it is to work intuitively between two OrderedDicts. It doesn't look like a common principle in Python. Witness: >>> list(range(3)) == set(range(3)) False >>> list(range(3)) == tuple(range(3)) False >>> 1 == Decimal(1) True >>> 1 == 1.0 True >>> 1.0 == Decimal(1) False IMO, comparison between different types should be "best effort", and not at the price of making comparison between values of the same type less intuitive. > It's just asking > for problems and it introduces an unnecessary difference > from regular dicts. What you call an "unnecessary difference" seems to be the whole motivation for introducing OrderedDicts. I see no point in trying to mitigate that difference if the new type is to be genuinely useful. > Given that either choice will be surprising to someone, we opted > for the simplest API with the fewest special cases But the current __eq__ does look like a special case, given the intended semantics of the new datatype. Not having a special case would imply having an ordering-sensitive comparison. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
