change of random state when pyc created??

Steven D'Aprano steve at REMOVE.THIS.cybersource.com.au
Wed May 9 22:46:05 EDT 2007


On Wed, 09 May 2007 16:01:02 -0500, Robert Kern wrote:

> Alan G Isaac wrote:
>> Robert Kern wrote:
>>> http://docs.python.org/lib/typesmapping.html
>>> """
>>> Keys and values are listed in an arbitrary order which is non-random, varies
>>> across Python implementations, and depends on the dictionary's history of
>>> insertions and deletions.
>>> """
>> 
>> Even this does not tell me that if I use a specified implementation
>> that my results can vary from run to run.  That is, it still does
>> not communicate that rerunning an *unchanged* program with an
>> *unchanged* implementation can produce a change in results.
> 
> The last clause does tell me that.

Actually it doesn't. If you run a program twice, with the same inputs,
and no other source of randomness (or at most have pseudo-randomness
starting with the same seed), then the dictionary will have the same
history of insertions and deletions from run to run.

Go back to Peter Otten's diagnosis of the issue:

"... your GridPlayer instances are located in different memory locations
and get different hash values. This in turn affects the order in which
they occur when you iterate over the GridPlayer.players_played set."

There is nothing in there about the dictionary having a different history
of insertions and deletions. It is having the same insertions and
deletions each run, but the items being inserted are located at different
memory locations, and _that_ changes their hash value and hence the order
they occur in when you iterate over the set.

That's quite a subtle thread to follow, and with all respect Robert, it's
easy to say it is obvious in hindsight, but I didn't notice you solving
the problem in the first place. Maybe you would have, if you had tried...
and maybe you would have scratched your head too. Who can tell?

As Carsten Haese says in another post:

"The documentation shouldn't be expected to list every little thing that
might change the order of keys in a dictionary. The documentation does say
explicitly what *is* guaranteed: Order of keys is preserved as long as no
intervening modifications happen to the dictionary. Tearing down the
interpreter, starting it back up, and rebuilding the dictionary from
scratch is very definitely an intervening modification."

That's all very true, but nevertheless it is a significant gotcha. It is
natural to expect two runs of any program to give the same result if there
are (1) no random numbers involved; (2) the same input data; (3) and no
permanent storage from run to run. One doesn't normally expect the output
of a well-written, bug-free program to depend on the memory location of
objects. And that's the gotcha -- with dicts and sets, they can.



-- 
Steven.




More information about the Python-list mailing list