3 ms·

dict_keys(['c', 'd', 'e', 'b', 'a']) # random order > random Maybe I'm nit picky but I find the misuse of that word annoying. My experience of CPython is th

dict_keys(['c', 'd', 'e', 'b', 'a']) # random order > random Maybe I'm nit picky but I find the misuse of that word annoying. My experience of CPython is that dicts are unordered but deterministic. Not random.

thomasahle 10y ago
If your hash function is random (seeded), the order will be random over the seed.
- Pirate-of-SV 10y ago
  Across processes perhaps? But hash(a) == hash(a) and hash(b) == hash(b) so a dictionary that with a and b inserted will yield the same order every time. d1 = dict() d1['a'] = 1 d1['b'] = 1 print(d1.keys()) d2 = dict() d2['a'] = 1 d2['b'] = 1 print(d2.keys())
  - thomasahle 10y ago
    Yes across processes. You don't want to change (reseed) the hash function after the dictionary is created. (At least then you need to rehash everything.) Seeded hashing was introduced to python 3.2.3: https://docs.python.org/3.3/using/cmdline.html#cmdoption-R https://docs.python.org/3.3/using/cmdline.html#cmdoption-R $ python3 --version Python 3.5.2 $ python3 -c "print(hash('a'))" 6106879154137036349 $ python3 -c "print(hash('a'))" 9160572615033669802 $ python3 -c "print(set('abcdef'))" {'d', 'f', 'e', 'b', 'c', 'a'} $ python3 -c "print(set('abcdef'))" {'e', 'f', 'd', 'a', 'b', 'c'} Note that there is no guarantee that this ordering is uniformly random. (Though it probably is.)
  - Veedrac 10y ago
    The order of the keys in a dictionary was merely guaranteed to be consistent for a given instance: that is d1 is d2 ⇒ list(d1) == list(d2) But the order is not guaranteed to be consistent between two equal dictionaries, in that d1 == d2 ⇏ list(d1) == list(d2) This is because the history of the dictionary can affect its order, not just its contents. For example, x = {-1: (), -2: ()} y = {-2: (), -1: ()} list(x) != list(y) This remains true, but now the particular order produced from a given list of insert and delete operations is well-defined, rather than arbitrary. It's worth noting that previously the order of two dictionaries with the same history was also the same (but may vary between program runs), but that was not guaranteed. It's not actually clear if this is still regarded as an implementation detail, but I expect it will be effectively impossible to stop this becoming a key assumption of many libraries, so would expect any attempt to require OrderedDict (except for pre-3.6 compatibility) will fail.
  - deleted 10y ago
    [deleted]
creshal 10y ago
Stable, but not in insertion order or any other order I'd call deterministic.
- marcosdumay 10y ago
  Deterministic means it is completely determined by the parameters, so it doesn't change from one call to another. This seems to be exactly what you are naming "stable" here. If it outputed the keys in a known order, it would be predictable. Yet, the GP is just complaining about two different and widespread definitions of "random", so, whatever. It would be great to have a contexts dictionary we could use to resolve such things.
kzrdude 10y ago
They should say "arbitrary order"
- grumpopotamus 10y ago
  How about unspecified order?

thomasahle 10y ago

If your hash function is random (seeded), the order will be random over the seed.

Pirate-of-SV 10y ago
Across processes perhaps? But hash(a) == hash(a) and hash(b) == hash(b) so a dictionary that with a and b inserted will yield the same order every time. d1 = dict() d1['a'] = 1 d1['b'] = 1 print(d1.keys()) d2 = dict() d2['a'] = 1 d2['b'] = 1 print(d2.keys())
- thomasahle 10y ago
  Yes across processes. You don't want to change (reseed) the hash function after the dictionary is created. (At least then you need to rehash everything.) Seeded hashing was introduced to python 3.2.3: https://docs.python.org/3.3/using/cmdline.html#cmdoption-R https://docs.python.org/3.3/using/cmdline.html#cmdoption-R $ python3 --version Python 3.5.2 $ python3 -c "print(hash('a'))" 6106879154137036349 $ python3 -c "print(hash('a'))" 9160572615033669802 $ python3 -c "print(set('abcdef'))" {'d', 'f', 'e', 'b', 'c', 'a'} $ python3 -c "print(set('abcdef'))" {'e', 'f', 'd', 'a', 'b', 'c'} Note that there is no guarantee that this ordering is uniformly random. (Though it probably is.)
- Veedrac 10y ago
  The order of the keys in a dictionary was merely guaranteed to be consistent for a given instance: that is d1 is d2 ⇒ list(d1) == list(d2) But the order is not guaranteed to be consistent between two equal dictionaries, in that d1 == d2 ⇏ list(d1) == list(d2) This is because the history of the dictionary can affect its order, not just its contents. For example, x = {-1: (), -2: ()} y = {-2: (), -1: ()} list(x) != list(y) This remains true, but now the particular order produced from a given list of insert and delete operations is well-defined, rather than arbitrary. It's worth noting that previously the order of two dictionaries with the same history was also the same (but may vary between program runs), but that was not guaranteed. It's not actually clear if this is still regarded as an implementation detail, but I expect it will be effectively impossible to stop this becoming a key assumption of many libraries, so would expect any attempt to require OrderedDict (except for pre-3.6 compatibility) will fail.
- deleted 10y ago
  [deleted]

creshal 10y ago

Stable, but not in insertion order or any other order I'd call deterministic.

marcosdumay 10y ago
Deterministic means it is completely determined by the parameters, so it doesn't change from one call to another. This seems to be exactly what you are naming "stable" here. If it outputed the keys in a known order, it would be predictable. Yet, the GP is just complaining about two different and widespread definitions of "random", so, whatever. It would be great to have a contexts dictionary we could use to resolve such things.

kzrdude 10y ago

They should say "arbitrary order"

grumpopotamus 10y ago
How about unspecified order?