Larry Hastings added the comment: 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".) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19664> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
