Dictionaries should not be assumed to keep their orderings anyway.

That's why there's OrderredDict.

Unless the language explicitly says that dicts hold their order, even if they do, it's an implementation detail, and it should not be relied upon.

As of 3.7 (3.6 for cpython), dictionaries have a deterministic order.

What's the best way to write code that relies on this deterministic order and prevent it from running incorrectly with older python versions?

Import collections.OrderedDict as you would have done beforehand. There are still some differences between them.

(Dicts in 3.7 and ordered dicts)

https://stackoverflow.com/questions/50872498/will-ordereddic...

If "the language explicitly says" something, then it's part of the specification and not an implementation detail.

Sure, hence the "unless" I've used.

I think this behavior will only be working starting from Python 3.6, as the dictionary obtained by calling `dict.fromkeys()` before this would not keep the ordering [1]

[1] https://youtu.be/p33CVV29OG8?t=489

I love that talk. Raymond Hettinger is a gem. What I took from that is the implementation does preserve order but it isn't guaranteed yet and in theory it could change.

> I love that talk. Raymond Hettinger is a gem.

This talk is definitely worth a watch yes :)

> What I took from that is the implementation does preserve order but it isn't guaranteed yet and in theory it could change.

This was the case for python 3.6, but starting from Python 3.7 ordering is guaranteed [1]:

  Changed in version 3.7: Dictionary order is guaranteed to be insertion order.

[1] https://docs.python.org/3.7/library/stdtypes.html#dict-views

> Raymond Hettinger is a gem.

His talks are good, except that every time he asks a stupid rhetorical question of the audience I’m overwhelmed with the urge to wang¹ a tomato at him.

1. https://www.gunnerkrigg.com/?p=330

In Python 3.6+, dictionaries preserve insertion order. This is done by storing the keys, values (and cached hash values) in a separate array, and the hashtable is a succinct array of indexes into this array. This results in more compact dictionaries, which are also a bit faster because of it's cache friendliness. Preserving insertion order is a happy side effect of this. This optimization can also be applied to Python sets, but it hasn't been done yet.

More importantly, in Python 3.7 this exception has become the rule, i.e. it was introduced in the language specification

I am personally not a fan of details like this creeping into the language spec. CPython is not the only Python. This kind of spec creates unnecessary challenges for Micropython, for example. And of course there is Cython and others. It makes no sense to me that this should be in the language spec — you are essentially specifying a built in minefield of implementation bugs.

Cpython took this implementation detail from pypy (so it was already going to be the case in the two most used python implementations).

The reason being that the ordered dict ends up being faster than non-ordered, and people will rely on this implementation detail, so they added it to the spec to make that okay.

Well I'll be dipped.

I'm not sure what you're trying to imply. If it's regarding the order, you're wrong. The keys returned by either `keys()` or by `__iter__` are returned in arbitrary order [1].

[1] https://docs.python.org/2/tutorial/datastructures.html#dicti...

The whole cheatsheet is clearly in Python 3, where the same doc page that you linked states:

   Performing list(d) on a dictionary returns a list of all the keys used in the dictionary, in 
   insertion order ...

only specified as such since Python 3.7, which hadn't been released when this cheat sheet was written, at least if the date at the top is accurate.

EDIT: clicking through to GitHub, the date is clearly not up-to-date, so this might have been added later.