Why __hash__() does not return an UUID4?

[Chris Angelico]

On Thu, Aug 27, 2020 at 7:52 AM Richard Damon <Richard at damon-family.org> wrote:
>
> On 8/26/20 5:13 PM, 2QdxY4RzWzUUiLuE at potatochowder.com wrote:
> > On 2020-08-26 at 22:10:26 +0200,
> > Marco Sulla <Marco.Sulla.Python at gmail.com> wrote:
> >
> >> As title ...
> > Assuming that the title appears prominently with the content of your
> > email.  For the rest of us:
> >
> >     Why __hash__() does not return an UUID4?
> >
> >> ... The reasons that came in my mind are:
> >>
> >> 1. speed
> >> 2. security
> > Correctness?
> >
> > Why would __hash__() return a random number?  An important property of
> > hashes is that if x == y, then hash(x) == hash(y).  If hash(x) and
> > hash(y) were random numbers, then how would this property be maintained?
> >
> > Or do UUID4 mean something else to you than a random number?
>
> Looking up which UUID type 4 is, yes it is a random number, so could
> only be applicable for objects that currently return id(), which could
> instead make id() be a UUID4 (and save it in the object, increasing its
> side)
>

I can't see how this is any benefit over any other definition, but if
someone wants to propose that id() return a UUID4, then that would be
entirely separate from anything regarding hash. As long as there's an
absolute guarantee that the same ID will never be used for two objects
at once, it's fine to generate them any way you like.

ChrisA