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.
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