On Sun, 15 Jan 2012 17:46:36 +0100 Stefan Behnel <stefan_ml at behnel.de> wrote: > Guido van Rossum, 15.01.2012 17:10: > > On Sun, Jan 15, 2012 at 6:30 AM, Stefan Behnel 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? > > No, I mean that the hash() builtin function is not the right place to > document the behaviour of a string hash. That should go into the string > object documentation. No, but we can document that *any* hash() value can vary between runs without being specific about which builtin types randomize their hashes right now. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4