On Sun, Jan 15, 2012 at 6:30 AM, Stefan Behnel <stefan...@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com