4 ms·

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.

by schoen 5y ago

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#ordereddict-objects https://docs.python.org/3/library/collections.html#ordereddi...

flafla2 5y ago
Funny, I just found out about this today. Infuriatingly, this behavior is _not_ preserved for the set type.
- masklinn 5y ago
  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))
  - comex 5y ago
    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.
- raverbashing 5y ago
  If you need an ordered set just use the time proven tradition of "poor man's set" in Python: (now ordered) dict keys
ComodoHacker 5y ago
This is going to be a time bomb, preventing inplementation improvements (or even vulnerability fixes) in the future.
josefx 5y ago
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.
kevincox 5y ago
IIRC Python in the past deliberately randomized the order, then later deliberately fixed the order. Both in the 3.x series.

by schoen 5y ago

flafla2 5y ago

Funny, I just found out about this today. Infuriatingly, this behavior is _not_ preserved for the set type.

masklinn 5y ago
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))
- comex 5y ago
  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.
raverbashing 5y ago
If you need an ordered set just use the time proven tradition of "poor man's set" in Python: (now ordered) dict keys

ComodoHacker 5y ago

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

josefx 5y ago

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.

kevincox 5y ago

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