[Python-Dev] getting rid of default object.__hash__ (SF 660098)

Samuele Pedroni pedronis at bluewin.ch
Mon Dec 22 16:55:48 EST 2003

At 13:43 22.12.2003 -0800, Guido van Rossum wrote:
> > > > I see, but then there should be probably be a different way to spell
> > > > the default hash, because id is not a sensible option for Jython etc
> > >
> > >Ow, you're right.  I bet this is why object.__hash__ was introduced in
> > >the first place.
> > >
> > >We're either back to square one, or we can add a __default_hash__ to
> > >object which has the default hash implementation -- this isn't very
> > >pretty but at least it works.
> >
> > yes, or hash should grow a keyword argument to get access to the default
> > impl, which would be id for CPython but not for all Python impls in
> > general. The problem is that in general it cannot be expected from Python
> > implementations to implement the default hash in terms of id because the
> > latter can be much more costly beacuse of its uniqueness constraints.
>Hm, the keyword arg would be more work to implement in C, and I don't
>really like the ad-hoc extension of the __hash__ signature -- it may
>make subclasses think they have to support the keyword too.
>(Overriding the __default_hash__ would be possible, but silly, and I
>recommend not to support this; if this were Java I'd make it a final
>method.  Can you make it final in Jython?)

internally yes. But I would probably hardcode is usage in hash, so that is 
just a way to access the default hash impl and nothing more.

More information about the Python-Dev mailing list