This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author larry
Recipients larry, pitrou, rhettinger, vstinner
Date 2013-11-20.19:35:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1384976116.94.0.442795145588.issue19664@psf.upfronthosting.co.za>
In-reply-to
Content
I don't know for sure--I haven't stepped through it--but here's an informed guess.  It relies on key collision.

The first dict is created the normal way.  It contains two values, "one" (set to 1) and "two" (set to 2), inserted in that order.

The second dict is created by calling dict.update(), passing in the first dict.  update() iterates over the keys of the dict's hash table with a simple for(;;) loop, copying the key and value each time.  The order is effectively random.

The repr() then iterates over the keys using the same simple for(;;) loop, spitting out key=value strings.

Let's assume that the keys collide.  "one" is inserted first, so it gets its first choice.  "two" is inserted second so it must probe.  Let's assume that its second choice is a key slot *lower* (nearer to [0]) than "one".

Now when we use update(), the for(;;) loop sees "two" first.  So "two" gets its first choice, which means "one" must now probe.  If "one"'s second choice is a key slot *higher* (further from [0]) than "two", we'll see the behavior.

(Why does this only happen sometimes?  Because we're using "hash randomization".)
History
Date User Action Args
2013-11-20 19:35:16larrysetrecipients: + larry, rhettinger, pitrou, vstinner
2013-11-20 19:35:16larrysetmessageid: <1384976116.94.0.442795145588.issue19664@psf.upfronthosting.co.za>
2013-11-20 19:35:16larrylinkissue19664 messages
2013-11-20 19:35:16larrycreate