Hacker News Reader

Comment by schoen | Hacker News Reader

Interestingly, Python deliberately changed it in the other direction. Since Python 3.7, the iteration order is guaranteed to be the same as the insertion order.

This was previously a special object (collections.OrderedDict) but is now the default behavior of every dict:

https://docs.python.org/3/library/collections.html#ordereddi...

View on HN

Python probably still does the same under the hood as the randomized hash was required to harden web frameworks against a denial of service attack that used long lists of keys with colliding hashes to force a worst case runtime.

Funny, I just found out about this today.

Infuriatingly, this behavior is _not_ preserved for the set type.

Yes that is because sets have their own hashmap implementation and the dev team remains so far unconvinced of the value of “unique lists”, and the primary gains of the new scheme might be nonexistent or of low impact for the set situation (for python the ordering properties were an ancillary change, not the reason for them))

I was just bitten by this the other day. In my case, it's not that I cared about any specific order ("unique lists"), but I did need the output to be deterministic for a caching mechanism to work properly. I knew dicts would 'just work' because of the ordering guarantee, but I was surprised to learn sets didn't. In the end the easiest fix was to just reimplement a set type on top of dict.

If you need an ordered set just use the time proven tradition of "poor man's set" in Python: (now ordered) dict keys

IIRC Python in the past deliberately randomized the order, then later deliberately fixed the order. Both in the 3.x series.

This is going to be a time bomb, preventing inplementation improvements (or even vulnerability fixes) in the future.

Reply on news.ycombinator.com