Hashability questions

Chris Angelico rosuav at gmail.com
Tue May 15 03:30:32 EDT 2012


On Tue, May 15, 2012 at 3:27 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> Why?  I can't see any purpose in implementing __eq__ this way, but I
> don't see how it's "broken" (assuming that __hash__ is actually
> implemented somehow and doesn't just raise TypeError).  The
> requirement is that if two objects compare equal, then they must have
> the same hash, and that clearly holds true here.
>
> Can you give a concrete example that demonstrates how this __eq__
> method is dangerous and broken?

Its brokenness is that hash collisions result in potentially-spurious
equalities. But I can still invent a (somewhat contrived) use for such
a setup:


class Modulo:
	base = 256
	def __init__(self,n):
		self.val=int(n)
	def __str__(self):
		return str(self.val)
	__repr__=__str__
	def __hash__(self):
		return self.val%self.base
	def __eq__(self,other):
		return hash(self)==hash(other)
	def __iadd__(self,other):
		try:
			self.val+=other.val
		except:
			try:
				self.val+=int(other)
			except:
				pass
		return self

Two of these numbers will hash and compare equal if they are equal
modulo 'base'. Useful? Probably not. But it's plausibly defined.

ChrisA



More information about the Python-list mailing list