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/%7Eguido/)