Why is dictionary ordering non-deterministic?
I recently switched from Python 2.7 to Python 3.3, and it seems that while in Python 2 the ordering of dictionary keys was arbitrary but consistent, in Python 3 the ordering of the keys of a dictionary obtained with e.g. vars()
appears non-deterministic.
If I run:
class Test(object): pass
parameters = vars(Test)
print(list(parameters.keys()))
in both Python 2.7 and Python 3.3, then:
Python 2.7 consistently gives me
['__dict__', '__module__', '__weakref__', '__doc__']
With Python 3.3, I can get any random order – for example:
['__weakref__', '__module__', '__qualname__', '__doc__', '__dict__']
['__doc__', '__dict__', '__qualname__', '__module__', '__weakref__']
['__dict__', '__module__', '__qualname__', '__weakref__', '__doc__']
['__weakref__', '__doc__', '__qualname__', '__dict__', '__module__']
Where does this non-determinism come from? And why is something like
list({str(i): i for i in range(10)}.keys())
… consistent between runs, always giving
['3', '2', '1', '0', '7', '6', '5', '4', '9', '8']
… ?
python dictionary python-3.x python-3.3 non-deterministic
add a comment |
I recently switched from Python 2.7 to Python 3.3, and it seems that while in Python 2 the ordering of dictionary keys was arbitrary but consistent, in Python 3 the ordering of the keys of a dictionary obtained with e.g. vars()
appears non-deterministic.
If I run:
class Test(object): pass
parameters = vars(Test)
print(list(parameters.keys()))
in both Python 2.7 and Python 3.3, then:
Python 2.7 consistently gives me
['__dict__', '__module__', '__weakref__', '__doc__']
With Python 3.3, I can get any random order – for example:
['__weakref__', '__module__', '__qualname__', '__doc__', '__dict__']
['__doc__', '__dict__', '__qualname__', '__module__', '__weakref__']
['__dict__', '__module__', '__qualname__', '__weakref__', '__doc__']
['__weakref__', '__doc__', '__qualname__', '__dict__', '__module__']
Where does this non-determinism come from? And why is something like
list({str(i): i for i in range(10)}.keys())
… consistent between runs, always giving
['3', '2', '1', '0', '7', '6', '5', '4', '9', '8']
… ?
python dictionary python-3.x python-3.3 non-deterministic
add a comment |
I recently switched from Python 2.7 to Python 3.3, and it seems that while in Python 2 the ordering of dictionary keys was arbitrary but consistent, in Python 3 the ordering of the keys of a dictionary obtained with e.g. vars()
appears non-deterministic.
If I run:
class Test(object): pass
parameters = vars(Test)
print(list(parameters.keys()))
in both Python 2.7 and Python 3.3, then:
Python 2.7 consistently gives me
['__dict__', '__module__', '__weakref__', '__doc__']
With Python 3.3, I can get any random order – for example:
['__weakref__', '__module__', '__qualname__', '__doc__', '__dict__']
['__doc__', '__dict__', '__qualname__', '__module__', '__weakref__']
['__dict__', '__module__', '__qualname__', '__weakref__', '__doc__']
['__weakref__', '__doc__', '__qualname__', '__dict__', '__module__']
Where does this non-determinism come from? And why is something like
list({str(i): i for i in range(10)}.keys())
… consistent between runs, always giving
['3', '2', '1', '0', '7', '6', '5', '4', '9', '8']
… ?
python dictionary python-3.x python-3.3 non-deterministic
I recently switched from Python 2.7 to Python 3.3, and it seems that while in Python 2 the ordering of dictionary keys was arbitrary but consistent, in Python 3 the ordering of the keys of a dictionary obtained with e.g. vars()
appears non-deterministic.
If I run:
class Test(object): pass
parameters = vars(Test)
print(list(parameters.keys()))
in both Python 2.7 and Python 3.3, then:
Python 2.7 consistently gives me
['__dict__', '__module__', '__weakref__', '__doc__']
With Python 3.3, I can get any random order – for example:
['__weakref__', '__module__', '__qualname__', '__doc__', '__dict__']
['__doc__', '__dict__', '__qualname__', '__module__', '__weakref__']
['__dict__', '__module__', '__qualname__', '__weakref__', '__doc__']
['__weakref__', '__doc__', '__qualname__', '__dict__', '__module__']
Where does this non-determinism come from? And why is something like
list({str(i): i for i in range(10)}.keys())
… consistent between runs, always giving
['3', '2', '1', '0', '7', '6', '5', '4', '9', '8']
… ?
python dictionary python-3.x python-3.3 non-deterministic
python dictionary python-3.x python-3.3 non-deterministic
edited Mar 12 '17 at 20:21
Zero Piraeus
29.8k1797125
29.8k1797125
asked Feb 19 '13 at 11:25
AnaphoryAnaphory
3,00512449
3,00512449
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Update: In Python 3.6, dict
has a new implementation which preserves insertion order. From Python 3.7, this order-preserving behaviour is guaranteed:
the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec.
This is the result of a security fix from 2012, which was enabled by default in Python 3.3 (scroll down to "Security improvements").
From the announcement:
Hash randomization causes the iteration order of dicts and sets to be
unpredictable and differ across Python runs. Python has never guaranteed
iteration order of keys in a dict or set, and applications are advised to never
rely on it. Historically, dict iteration order has not changed very often across
releases and has always remained consistent between successive executions of
Python. Thus, some existing applications may be relying on dict or set ordering.
Because of this and the fact that many Python applications which don't accept
untrusted input are not vulnerable to this attack, in all stable Python releases
mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT.
As noted above, the last, capitalized bit is no longer true in Python 3.3.
See also: object.__hash__()
documentation ("Note" sidebar).
If absolutely necessary, you can disable hash randomization in versions of Python affected by this behaviour by setting the PYTHONHASHSEED
environment variable to 0
.
Your counterexample:
list({str(i): i for i in range(10)}.keys())
… does not in fact always give the same result in Python 3.3, although the number of different orderings is limited due to the way hash collisions are handled:
$ for x in {0..999}
> do
> python3.3 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
61 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
73 ['1', '0', '3', '2', '5', '4', '7', '6', '9', '8']
62 ['2', '3', '0', '1', '6', '7', '4', '5', '8', '9']
59 ['3', '2', '1', '0', '7', '6', '5', '4', '9', '8']
58 ['4', '5', '6', '7', '0', '1', '2', '3', '8', '9']
55 ['5', '4', '7', '6', '1', '0', '3', '2', '9', '8']
62 ['6', '7', '4', '5', '2', '3', '0', '1', '8', '9']
63 ['7', '6', '5', '4', '3', '2', '1', '0', '9', '8']
60 ['8', '9', '0', '1', '2', '3', '4', '5', '6', '7']
66 ['8', '9', '2', '3', '0', '1', '6', '7', '4', '5']
65 ['8', '9', '4', '5', '6', '7', '0', '1', '2', '3']
53 ['8', '9', '6', '7', '4', '5', '2', '3', '0', '1']
62 ['9', '8', '1', '0', '3', '2', '5', '4', '7', '6']
52 ['9', '8', '3', '2', '1', '0', '7', '6', '5', '4']
73 ['9', '8', '5', '4', '7', '6', '1', '0', '3', '2']
76 ['9', '8', '7', '6', '5', '4', '3', '2', '1', '0']
As noted at the beginning of this answer, that's no longer the case in Python 3.6:
$ for x in {0..999}
> do
> python3.6 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
1000 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
1
So why does this not apply to something like{str(i): i for i in range(10)}
?
– Anaphory
Feb 19 '13 at 13:48
So how do we disable this randomization?
– nmz787
Jul 8 '16 at 18:12
3
@nmz787 docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
– Zero Piraeus
Jul 8 '16 at 20:53
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f14956313%2fwhy-is-dictionary-ordering-non-deterministic%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Update: In Python 3.6, dict
has a new implementation which preserves insertion order. From Python 3.7, this order-preserving behaviour is guaranteed:
the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec.
This is the result of a security fix from 2012, which was enabled by default in Python 3.3 (scroll down to "Security improvements").
From the announcement:
Hash randomization causes the iteration order of dicts and sets to be
unpredictable and differ across Python runs. Python has never guaranteed
iteration order of keys in a dict or set, and applications are advised to never
rely on it. Historically, dict iteration order has not changed very often across
releases and has always remained consistent between successive executions of
Python. Thus, some existing applications may be relying on dict or set ordering.
Because of this and the fact that many Python applications which don't accept
untrusted input are not vulnerable to this attack, in all stable Python releases
mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT.
As noted above, the last, capitalized bit is no longer true in Python 3.3.
See also: object.__hash__()
documentation ("Note" sidebar).
If absolutely necessary, you can disable hash randomization in versions of Python affected by this behaviour by setting the PYTHONHASHSEED
environment variable to 0
.
Your counterexample:
list({str(i): i for i in range(10)}.keys())
… does not in fact always give the same result in Python 3.3, although the number of different orderings is limited due to the way hash collisions are handled:
$ for x in {0..999}
> do
> python3.3 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
61 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
73 ['1', '0', '3', '2', '5', '4', '7', '6', '9', '8']
62 ['2', '3', '0', '1', '6', '7', '4', '5', '8', '9']
59 ['3', '2', '1', '0', '7', '6', '5', '4', '9', '8']
58 ['4', '5', '6', '7', '0', '1', '2', '3', '8', '9']
55 ['5', '4', '7', '6', '1', '0', '3', '2', '9', '8']
62 ['6', '7', '4', '5', '2', '3', '0', '1', '8', '9']
63 ['7', '6', '5', '4', '3', '2', '1', '0', '9', '8']
60 ['8', '9', '0', '1', '2', '3', '4', '5', '6', '7']
66 ['8', '9', '2', '3', '0', '1', '6', '7', '4', '5']
65 ['8', '9', '4', '5', '6', '7', '0', '1', '2', '3']
53 ['8', '9', '6', '7', '4', '5', '2', '3', '0', '1']
62 ['9', '8', '1', '0', '3', '2', '5', '4', '7', '6']
52 ['9', '8', '3', '2', '1', '0', '7', '6', '5', '4']
73 ['9', '8', '5', '4', '7', '6', '1', '0', '3', '2']
76 ['9', '8', '7', '6', '5', '4', '3', '2', '1', '0']
As noted at the beginning of this answer, that's no longer the case in Python 3.6:
$ for x in {0..999}
> do
> python3.6 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
1000 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
1
So why does this not apply to something like{str(i): i for i in range(10)}
?
– Anaphory
Feb 19 '13 at 13:48
So how do we disable this randomization?
– nmz787
Jul 8 '16 at 18:12
3
@nmz787 docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
– Zero Piraeus
Jul 8 '16 at 20:53
add a comment |
Update: In Python 3.6, dict
has a new implementation which preserves insertion order. From Python 3.7, this order-preserving behaviour is guaranteed:
the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec.
This is the result of a security fix from 2012, which was enabled by default in Python 3.3 (scroll down to "Security improvements").
From the announcement:
Hash randomization causes the iteration order of dicts and sets to be
unpredictable and differ across Python runs. Python has never guaranteed
iteration order of keys in a dict or set, and applications are advised to never
rely on it. Historically, dict iteration order has not changed very often across
releases and has always remained consistent between successive executions of
Python. Thus, some existing applications may be relying on dict or set ordering.
Because of this and the fact that many Python applications which don't accept
untrusted input are not vulnerable to this attack, in all stable Python releases
mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT.
As noted above, the last, capitalized bit is no longer true in Python 3.3.
See also: object.__hash__()
documentation ("Note" sidebar).
If absolutely necessary, you can disable hash randomization in versions of Python affected by this behaviour by setting the PYTHONHASHSEED
environment variable to 0
.
Your counterexample:
list({str(i): i for i in range(10)}.keys())
… does not in fact always give the same result in Python 3.3, although the number of different orderings is limited due to the way hash collisions are handled:
$ for x in {0..999}
> do
> python3.3 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
61 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
73 ['1', '0', '3', '2', '5', '4', '7', '6', '9', '8']
62 ['2', '3', '0', '1', '6', '7', '4', '5', '8', '9']
59 ['3', '2', '1', '0', '7', '6', '5', '4', '9', '8']
58 ['4', '5', '6', '7', '0', '1', '2', '3', '8', '9']
55 ['5', '4', '7', '6', '1', '0', '3', '2', '9', '8']
62 ['6', '7', '4', '5', '2', '3', '0', '1', '8', '9']
63 ['7', '6', '5', '4', '3', '2', '1', '0', '9', '8']
60 ['8', '9', '0', '1', '2', '3', '4', '5', '6', '7']
66 ['8', '9', '2', '3', '0', '1', '6', '7', '4', '5']
65 ['8', '9', '4', '5', '6', '7', '0', '1', '2', '3']
53 ['8', '9', '6', '7', '4', '5', '2', '3', '0', '1']
62 ['9', '8', '1', '0', '3', '2', '5', '4', '7', '6']
52 ['9', '8', '3', '2', '1', '0', '7', '6', '5', '4']
73 ['9', '8', '5', '4', '7', '6', '1', '0', '3', '2']
76 ['9', '8', '7', '6', '5', '4', '3', '2', '1', '0']
As noted at the beginning of this answer, that's no longer the case in Python 3.6:
$ for x in {0..999}
> do
> python3.6 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
1000 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
1
So why does this not apply to something like{str(i): i for i in range(10)}
?
– Anaphory
Feb 19 '13 at 13:48
So how do we disable this randomization?
– nmz787
Jul 8 '16 at 18:12
3
@nmz787 docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
– Zero Piraeus
Jul 8 '16 at 20:53
add a comment |
Update: In Python 3.6, dict
has a new implementation which preserves insertion order. From Python 3.7, this order-preserving behaviour is guaranteed:
the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec.
This is the result of a security fix from 2012, which was enabled by default in Python 3.3 (scroll down to "Security improvements").
From the announcement:
Hash randomization causes the iteration order of dicts and sets to be
unpredictable and differ across Python runs. Python has never guaranteed
iteration order of keys in a dict or set, and applications are advised to never
rely on it. Historically, dict iteration order has not changed very often across
releases and has always remained consistent between successive executions of
Python. Thus, some existing applications may be relying on dict or set ordering.
Because of this and the fact that many Python applications which don't accept
untrusted input are not vulnerable to this attack, in all stable Python releases
mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT.
As noted above, the last, capitalized bit is no longer true in Python 3.3.
See also: object.__hash__()
documentation ("Note" sidebar).
If absolutely necessary, you can disable hash randomization in versions of Python affected by this behaviour by setting the PYTHONHASHSEED
environment variable to 0
.
Your counterexample:
list({str(i): i for i in range(10)}.keys())
… does not in fact always give the same result in Python 3.3, although the number of different orderings is limited due to the way hash collisions are handled:
$ for x in {0..999}
> do
> python3.3 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
61 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
73 ['1', '0', '3', '2', '5', '4', '7', '6', '9', '8']
62 ['2', '3', '0', '1', '6', '7', '4', '5', '8', '9']
59 ['3', '2', '1', '0', '7', '6', '5', '4', '9', '8']
58 ['4', '5', '6', '7', '0', '1', '2', '3', '8', '9']
55 ['5', '4', '7', '6', '1', '0', '3', '2', '9', '8']
62 ['6', '7', '4', '5', '2', '3', '0', '1', '8', '9']
63 ['7', '6', '5', '4', '3', '2', '1', '0', '9', '8']
60 ['8', '9', '0', '1', '2', '3', '4', '5', '6', '7']
66 ['8', '9', '2', '3', '0', '1', '6', '7', '4', '5']
65 ['8', '9', '4', '5', '6', '7', '0', '1', '2', '3']
53 ['8', '9', '6', '7', '4', '5', '2', '3', '0', '1']
62 ['9', '8', '1', '0', '3', '2', '5', '4', '7', '6']
52 ['9', '8', '3', '2', '1', '0', '7', '6', '5', '4']
73 ['9', '8', '5', '4', '7', '6', '1', '0', '3', '2']
76 ['9', '8', '7', '6', '5', '4', '3', '2', '1', '0']
As noted at the beginning of this answer, that's no longer the case in Python 3.6:
$ for x in {0..999}
> do
> python3.6 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
1000 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
Update: In Python 3.6, dict
has a new implementation which preserves insertion order. From Python 3.7, this order-preserving behaviour is guaranteed:
the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec.
This is the result of a security fix from 2012, which was enabled by default in Python 3.3 (scroll down to "Security improvements").
From the announcement:
Hash randomization causes the iteration order of dicts and sets to be
unpredictable and differ across Python runs. Python has never guaranteed
iteration order of keys in a dict or set, and applications are advised to never
rely on it. Historically, dict iteration order has not changed very often across
releases and has always remained consistent between successive executions of
Python. Thus, some existing applications may be relying on dict or set ordering.
Because of this and the fact that many Python applications which don't accept
untrusted input are not vulnerable to this attack, in all stable Python releases
mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT.
As noted above, the last, capitalized bit is no longer true in Python 3.3.
See also: object.__hash__()
documentation ("Note" sidebar).
If absolutely necessary, you can disable hash randomization in versions of Python affected by this behaviour by setting the PYTHONHASHSEED
environment variable to 0
.
Your counterexample:
list({str(i): i for i in range(10)}.keys())
… does not in fact always give the same result in Python 3.3, although the number of different orderings is limited due to the way hash collisions are handled:
$ for x in {0..999}
> do
> python3.3 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
61 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
73 ['1', '0', '3', '2', '5', '4', '7', '6', '9', '8']
62 ['2', '3', '0', '1', '6', '7', '4', '5', '8', '9']
59 ['3', '2', '1', '0', '7', '6', '5', '4', '9', '8']
58 ['4', '5', '6', '7', '0', '1', '2', '3', '8', '9']
55 ['5', '4', '7', '6', '1', '0', '3', '2', '9', '8']
62 ['6', '7', '4', '5', '2', '3', '0', '1', '8', '9']
63 ['7', '6', '5', '4', '3', '2', '1', '0', '9', '8']
60 ['8', '9', '0', '1', '2', '3', '4', '5', '6', '7']
66 ['8', '9', '2', '3', '0', '1', '6', '7', '4', '5']
65 ['8', '9', '4', '5', '6', '7', '0', '1', '2', '3']
53 ['8', '9', '6', '7', '4', '5', '2', '3', '0', '1']
62 ['9', '8', '1', '0', '3', '2', '5', '4', '7', '6']
52 ['9', '8', '3', '2', '1', '0', '7', '6', '5', '4']
73 ['9', '8', '5', '4', '7', '6', '1', '0', '3', '2']
76 ['9', '8', '7', '6', '5', '4', '3', '2', '1', '0']
As noted at the beginning of this answer, that's no longer the case in Python 3.6:
$ for x in {0..999}
> do
> python3.6 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
1000 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
edited Nov 20 '18 at 7:19
answered Feb 19 '13 at 13:42
Zero PiraeusZero Piraeus
29.8k1797125
29.8k1797125
1
So why does this not apply to something like{str(i): i for i in range(10)}
?
– Anaphory
Feb 19 '13 at 13:48
So how do we disable this randomization?
– nmz787
Jul 8 '16 at 18:12
3
@nmz787 docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
– Zero Piraeus
Jul 8 '16 at 20:53
add a comment |
1
So why does this not apply to something like{str(i): i for i in range(10)}
?
– Anaphory
Feb 19 '13 at 13:48
So how do we disable this randomization?
– nmz787
Jul 8 '16 at 18:12
3
@nmz787 docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
– Zero Piraeus
Jul 8 '16 at 20:53
1
1
So why does this not apply to something like
{str(i): i for i in range(10)}
?– Anaphory
Feb 19 '13 at 13:48
So why does this not apply to something like
{str(i): i for i in range(10)}
?– Anaphory
Feb 19 '13 at 13:48
So how do we disable this randomization?
– nmz787
Jul 8 '16 at 18:12
So how do we disable this randomization?
– nmz787
Jul 8 '16 at 18:12
3
3
@nmz787 docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
– Zero Piraeus
Jul 8 '16 at 20:53
@nmz787 docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
– Zero Piraeus
Jul 8 '16 at 20:53
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f14956313%2fwhy-is-dictionary-ordering-non-deterministic%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown