[Python-Dev] Status of the fix for the hash collision vulnerability (original) (raw)
Stefan Behnel stefan_ml at behnel.de
Sun Jan 15 15:30:59 CET 2012
- Previous message: [Python-Dev] Status of the fix for the hash collision vulnerability
- Next message: [Python-Dev] Status of the fix for the hash collision vulnerability
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Terry Reedy, 14.01.2012 06:43:
On 1/13/2012 8:58 PM, Gregory P. Smith wrote:
It is perfectly okay to break existing users who had anything depending on ordering of internal hash tables. Their code was already broken. Given that the doc says "Return the hash value of the object", I do not think we should be so hard-nosed. The above clearly implies that there is such a thing as the Python hash value for an object. And indeed, that has been true across many versions. If we had written "Return a hash value for the object, which can vary from run to run", the case would be different.
Just a side note, but I don't think hash() is the right place to document this. Hashing is a protocol in Python, just like indexing or iteration. Nothing keeps an object from changing its hash value due to modification, and that would even be valid in the face of the usual dict lookup invariants if changes are only applied while the object is not referenced by any dict. So the guarantees do not depend on the function hash() and may be even weaker than your above statement.
Stefan
- Previous message: [Python-Dev] Status of the fix for the hash collision vulnerability
- Next message: [Python-Dev] Status of the fix for the hash collision vulnerability
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]