3 ms·
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 ord
by ali_m 3y ago
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.
- pphysch 3y agoI 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.
- ali_m 3y agoIf 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.
- necovek 3y agoYes, 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.