Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Since python 3.7, it is guaranteed that dictionaries maintain insertion order. The linked stackoverflow Q&A states
This simply means that you can depend on it.
Is it good practise to depend on this fact?
On the one hand it is a language feature and can be used. On the other hand, there are probably many python developers who don't expect that a change in the order of insertions to a dictionary would change the behaviour of the program. Is there a consensus on this matter?
It depends on which "Python developers" you're talking about.
If you're talking about co-workers who will help you write and maintain the code, the reliance on dict ordering should be discussed and decided upon beforehand. Ideally, everyone should be on the same page regarding language version/features and coding style. In-code reminders such as @timgeb 's example are also good.
On the other hand, if you're discussing consumers of your library code, you only need to warn about the Python >= 3.7 dependency. IMO we're all consenting adults, and it's not your job to educate your users about the language's features.
Although from a practical point of view, I'm struggling to think of a case where consumers should even care about such a specific implementation detail. You're probably better off creating an abstraction around the dict, so that users won't even have to wonder whether they're working with dictionaries in the first place (this of course depends on your actual use case).
So to answer the question, yes, I believe it's fine to depend on this feature. The actual question is whether you're fine with limiting your consumers to using Python >= 3.7 or not.
I rely on it, because I generally think new features should be used until they are well known. Until then, it would be nice to leave a comment for your colleagues such as
for k in my_dict:
# NOTE: relies on deterministic 3.7+ key ordering
and also to enforce that the project requires Python 3.7+.
On the other hand, I can see the argument for using a collections.OrderedDict even if you just need the insertion-ordering because it is more explicit and clear to everybody.
Unfortunately, OrderedDict is in a bit of an awkward state now. Since 3.7+, regular dicts provide its most prominent feature (insertion-ordering), but you can't just port over its lesser used methods (such as move_to_end) to regular dicts and remove OrderedDict from collections, because OrdereDict also takes the insertion-order into account for equality checks.
It's also weird to me that sets in 3.7+ don't provide insertion-ordering, even though I often think of dicts as sets of keys with associated values.
Honestly as I am writing this I'm kind of talking myself out of relying on dict insertion-ordering ...
