(original) (raw)

On Sun, Jan 15, 2012 at 6:30 AM, Stefan Behnel <stefan\_ml@behnel.de> wrote:

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.

You mean we shouldn't document that the hash() of a string will vary per run?
�

Hashing is a protocol in Python, just like indexing or iteration.

Nothing keeps an object from changing its hash value due to modification,

Eh? There's a huge body of cultural awareness that only immutable objects should define a hash, implying that the hash remains constant during the object's lifetime.
�

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.

And how would you know it isn't?
�

So the guarantees do not depend on the function hash() and may

be even weaker than your above statement.

There are no actual guarantees for hash(), but lots of rules for well-behaved hashes.

--
--Guido van Rossum (python.org/~guido)