ad-hoc __hash__ methods

[Lorenz Panny]

I've seen handrolled __hash__ methods in quite a few places: They
usually take individual hashes of the data defining the object and
combine them in some arbitrary-looking way.

Two examples I came across recently:
https://github.com/sagemath/sage/blob/9.4/src/sage/schemes/elliptic_curves/ell_curve_isogeny.py#L1216
https://github.com/sagemath/sage/blob/9.4/src/sage/algebras/quatalg/quaternion_algebra_element.pyx#L219

Q: Is there a good reason things done like this, rather than just
calling hash() on a tuple containing the data of the object?

[Nils Bruin]

I guess you're worried that h ^= h1; h ^=h2 gives the same result as h ^=h2; h ^=h1 ?

I think it makes sense to combine hashes without making an intermediate tuple. That would be unnecessary overhead. On the other hand, python's tuple hash indeed is quite careful to mix the consecutive object hashes quite carefully:

https://github.com/python/cpython/blob/7c4d96103c4e16161e9aed9a584c9857d0674099/Objects/tupleobject.c#L383

[Vincent Delecroix]

There is a lot of incoherence and inconsistencies in sage
hash functions. Two reasons that might explain the design in
some particular situation

* high hash collisions with tuple of integers in Python
(because hash(-1) is -2)

>>> hash((-1,-2)) == hash((-1,-1))
True

* speed. With your version the code would create a tuple (admittedly
this is rather fast).