Dicts already have confusing half-ordered, half-not semantics. As of 3.7 they are guaranteed to be insertion-ordered, but operators like == don't care about order.
I don't think it's confusing or even on the level of "semantics": looping over dict keys/elements is a common pattern and the 3.7 change makes that a little more predictable and consistent.
Two dicts with same elements not being equal would be surprising and confusing.
If we're treating them as ordered containers then it really ought to be surprising and confusing that two dicts with the same elements in a different order are considered equal. Other ordered containers such as lists or tuples don't behave this way.
I'd use an `OrderedDict` in situations where I have a mapping where the order of elements is significant. `OrderedDict` signals intent much more clearly, and its `__eq__` method cares about order.
Yes, but I hope nobody really relies on that ordering in their code, as, as you say, it is pretty inconsistent.
Eg. you can't rely on
dict_b_keys = iter(dict_b)
for key in dict_a:
value_a = dict_a[key]
value_b = dict_b[next(dict_b_keys)]
print(f"{value_a} == {value_b}: ", value_a == value_b)
The problem with the proposal is that it will be even stronger: you either require '*' to sort in-place (I assumed that would be even worse and thus unacceptable, so I ignored that case — it seems others believe that to be a more realistic implementation), or require dicts to maintain a half-sorted map of integer keys.
