Python 3 hashing

[QuLogic]

Several classes must be hashable because they are used as dictionary keys. This is generally implemented as a hash of the same information used for __eq__, or if that's not defined, the id.

[pelson]

I'm really surprised a namedtuple isn't hashable by default...

[rhattersley]

They are: 😕

$ python2
python 2.7.10 ...
>>> import collections
>>> hash(collections.namedtuple('Foo', 'foo bar')(1, 2))
3713081631934410656

$ python3
Python 3.4.3 ...
>>> import collections
>>> hash(collections.namedtuple('Foo', 'foo bar')(1, 2))
3713081631934410656

[QuLogic]

They are, but when you override __eq__, you must supply __hash__ as well. Unfortunately, you can't do something like __hash__ = namedtuple.__hash__ because namedtuple is actually a function and the real class is hidden. This implementation doesn't exactly match __eq__, but it should match Python 2 behaviour.

[rhattersley]

when you override __eq__, you must supply __hash__ as well

Seems to be a runtime check when you try to hash an object...

Python 3.4.3 ...
>>> import collections
>>> Foo = collections.namedtuple('Foo', 'foo bar')
>>> hash(Foo(1, 2))
3713081631934410656
>>> class Bar(Foo): __eq__ = lambda self, other: True
... 
>>> hash(Bar(1, 2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'Bar'

[rhattersley]

Seems to be a runtime check when you try to hash an object...

Or I could have just read @QuLogic's original commit message. 😒 Doh!

With new-style objects, if __eq__ is overridden, then __hash__ is automatically undefined.

>>> print(Foo.__hash__)
<slot wrapper '__hash__' of 'tuple' objects>
>>> print(Bar.__hash__)
None

[rhattersley]

So how about: super(_CoordMetaData, self).__hash__()?

[ajdawson]

Also raised in #962.

[rhattersley]

Probably more efficient as super(Cell, self).__hash__()?

[rhattersley]

If so, the same would apply for the other namedtuple subclasses in this PR.

[QuLogic]

I'm not sure it's more efficient, but I think it might be clearer that way. Just running %timeit hash(b) with the class in your example above shows super to be maybe 50 ns slower, but the slowest time is anywhere from 8 to 20-25 times slower for either method. So there's some sort of caching, but for that first hit, it seems to be a toss-up.

[rhattersley]

Thanks for checking 👍

[pelson]

👍 - nice solution

[pp-mo]

Re-investigated : this is still an issue.
It does not seem critical to merge after all, but it does affect other areas especially where we put Coords into sets, e.g. these:

• iris/lib/iris/analysis/cartography.py

  Line 747 in 2ccbc48

  coords_to_ignore.update(cube.coords(contains_dimension=xdim))

• iris/lib/iris/analysis/_interpolate_private.py

  Line 284 in 2ccbc48

  if cache is not None and cube in cache:

• iris/lib/iris/iterate.py

  Line 124 in 2ccbc48

  dimensioned_iter_coords.update(

Updated code comments to reflect it #2553.
Notes -- see: #2553 (comment)