> > > 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?) --Guido van Rossum (home page: http://www.python.org/~guido/)
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