Hi Terry, Thank you for you detailed email.
> If two collections are equal, should the iteration order be the same? It has > always been true that if hash values collide, insertion order matters. > However, a good hash function avoids hash collisions as much as possible in > practical use cases. Without doing something artificial, as I did with the > example, collisions should be especially rare on 64-bit builds. If one > collection has a series of additions and deletions so that the underlying > hash table has a different size than an equal collection build just from > insertions, then order will also be different. The reason that I asked to add the artificial example in the doc is because I never completely understand the unorderness until I see your artificial example. You will surely use more words for explaining what "unorderness" means than just showing your example. And the example (since formatted as code) is more eye catching than just plain text. For my case, since I didn't understand the unorderness, I made some subtle bug in my program, which works fine in my testing code. However, it produce a small amount of corrupted results for the real production use, which is harder to debug. It did wasted quite some of my time. > For the doc, the problem is what to say and where without being repetitous > (and to get multiple people to agree ;-). I agree that people have different opinions on issues like this. But I think that "The Customer Is God". Readers of the doc is the customers, the writers of the doc is the producers. The opinion of customers should carry more weight than producers. -- Regards, Peng -- http://mail.python.org/mailman/listinfo/python-list