Clarify why there's a ShardRange.__hash__

Code Issues Proposed changes

Change-Id: I4eff901aaa334c8a73cebfc578cea14d23e6c365

This commit is contained in:

Tim Burke

2025年06月16日 13:28:56 -07:00

parent 005d69d1a9

commit c177e7dcff

1 changed files with 7 additions and 5 deletions

@@ -4336,11 +4336,13 @@ class ShardRange(Namespace):

self.timestamp = timestamp or Timestamp.now()

return True

# A by-the-book implementation should probably hash the value, which

# in our case would be account+container+lower+upper (+timestamp ?).

# But we seem to be okay with just the identity.

def __hash__(self):

return id(self)

# It's a little funny that we're making this mutable class hashable, but

# we want to be able to map donor -> acceptor, shard range -> broker, etc.

# Since we override __eq__, we don't get Python's hashable-by-default,

# but we are happy to use their hash-derived-from-id().

# NB: this breaks Python's assumption that "Hashable objects which compare

# equal must have the same hash value."

__hash__ = object.__hash__

def __repr__(self):

return '%s<%r to %r as of %s, (%d, %d) as of %s, %s as of %s>' % (