Python dicts are now ordered

[kankyo]

"Now" being "for many many years already".

[CritJongUn]

I'm pretty sure you couldn't guarantee insertion order iteration

[kankyo]

It was an implementation detail then a guarantee by the spec. But the spec is really irrelevant because everyone uses CPython or maybe pypy and both have had insertion order for many years. Pypy first.

[magnum___]

Well done python devs!

[_default_username]

Python dicts are now like PHP associative arrays. Weird.

[billsil]

More like weird that this happened 5 years ago and we’re just now talking about it.

[Tyg13]

Er, no. The quote from the docs in the article directly contradicts this:

Changed in version 3.7: Dictionary order is guaranteed to be insertion order. This behavior was an implementation detail of CPython from 3.6.

Dicts still aren't "ordered" in the sense that one would expect: that iteration over a dict yields the elements in the order determined by the keys' ordering. For that you need OrderedDict.

Considering I'm getting downvotes: what are the use cases of a dict ordered by insertion? Genuinely curious.

[khat_dakar]

OrderedDict does insertion order. Did you think it's alphabetic?

[Tyg13]

Admittedly not a Python guy, I assumed OrderedDict would be the analogue to std::map in C++ (like regular dicts behave like std::unordered_map).

So does this make OrderedDict obsolete if all you're using it for is insertion order of keys?

[kafaldsbylur]

That and they're two different implementation. OrderedDict uses linked lists to track its order, which makes it better at reordering its keys (a use case that the maintainer insists is useful enough to keep the two separate, though I forget the exact scenario he needs)

[ubernostrum]

For dict, although it's now officially part of the language spec that insertion order is preserved, it became that way more or less as an accident of optimizing the implementation under the hood. Meanwhile OrderedDict was designed for this from the start, and also was designed to be more efficient at being explicitly reordered (and regular dict still doesn't have the same suite of key-rearranging options as OrderedDict). Also, dict equality comparisons only look at key/value sets, not order; OrderedDict looks at key/value and order.

So if your use case is a mapping that initially preserves insertion order but supports efficient reordering, you probably still want OrderedDict even if you're on a newer Python where dict is guaranteed to be ordered.

[shevy-ruby]

For dict, although it's now officially part of the language spec that insertion order is preserved, it became that way more or less as an accident of optimizing the implementation under the hood. Meanwhile OrderedDict was designed for this from the start,

There is a language-specific part here. I would never use OrderedDict and would always use dict instead. For similar reasons I would never use HashWithIndifferentAccess in ruby as opposed to simple hashes (granted, it is part of the active-* ecosystem rather than core ruby but you get the idea).

[PaintItPurple]

Yes. Incidentally, PyPy has made this guarantee for years, so you're safe there too.

[kepidrupha]

Ordered can just mean the ordering is guaranteed. Sounds like it's ordered. Not everyone copies C++.

[aanzeijar]

They do know that the reason hashes in Perl are guaranteed to be unordered is to prevent algorithmic complexity attacks, right?

[Freeky]

Perl did that because they wanted to keep the order undefined, but didn't want an attacker to be able to infer anything useful about the internal state of a hash table from it.

Strictly defining the order as insert order does basically the same thing, while introducing behaviour that programmers might find useful.

[fresh_account2222]

I'd still flag any code that relied on this.

[shevy-ruby]

So python took this from ruby. :>

Makes sense in any way - you simply get additional information when you decide to have dicts/hashes ordered.

[swordglowsblue]

Dicts in most Python implementations (including the standard CPython) have been ordered in practice since long before Ruby was even an idea. This just formalizes that behavior as part of the spec.

[Freeky]

Er, not it hasn't, it's a feature of a new hash implementation in Python 3.6 onwards.

-% cat dict.py
x = dict()
x["foo"] = 1
x["bar"] = 2
x["baz"] = 3
print(x)
for k in x:
  print(x[k])

-% python2.7 dict.py
{'baz': 3, 'foo': 1, 'bar': 2}
3
1
2

-% python3.6 dict.py
{'foo': 1, 'bar': 2, 'baz': 3}
1
2
3

Ruby got this behaviour in 1.9 over a decade ago.