On hashability and Substitutability of MultiIndexLocation vs. IndexLocation

[drewj-tp]

I saw this comment and I wonder when it's time to address the things the comment indicates should be addressed

armi/armi/reactor/grids/locations.py

Lines 369 to 371 in b436537

	# MIL's cannot be hashed, so we need to scrape off the implementation from
	# LocationBase. This raises some interesting questions of substitutability of the
	# various Location classes, which should be addressed.

Substitutability meaning you can't use a multiindexlocation in the same way you'd use an indexlocation, I presume. Should the multi be a subclass of the single index?

[john-science]

That's such a strange comment. Obviously, we can just implement our own def __hash__(self) method in any class we want. Why would that be impossible here?

[drewj-tp]

Speculating, but I think the comment stems from the mutability of the MultiIndexLocation

armi/armi/reactor/grids/locations.py

Lines 422 to 429 in b436537

	def append(self, location: IndexLocation):
	self._locations.append(location)
	def extend(self, locations: List[IndexLocation]):
	self._locations.extend(locations)
	def pop(self, location: IndexLocation):
	self._locations.pop(location)

If you made a MultiIndexLocation hashable based on the hash-values of its contained locations, the hash value would change as you add/remove more locations.

Trivially you could hash based off the id of the object. But then you can't substitute in another multi index location that has similar data

[john-science]

Sure, you have to DECIDE if the hash of a MultiIndexLocation depends on the full set of locations currently in it. But the hash of an object (nearly?) always depends on the state of that object. And if you want to decide otherwise, great.

Still, it seems more solvable than the comment suggests. There's a decision to make, is all.