[Python-Dev] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement

[Antoine Pitrou]

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.