An exercise to help build the right mental model for Python data.

  • Solution
  • Explanation: “User-defined classes have __eq__() and __hash__() methods by default (inherited from the object class); with them, all objects compare unequal (except with themselves) and x.__hash__() returns an appropriate value such that x == y implies both that x is y and hash(x) == hash(y).”

#Python #memory_graph #Equality #Hashing

  • Daniel Quinn@lemmy.caEnglish
    4·
    4 days ago

    That’s a very complicated way to explain it though.

    1. You basically create two object instances
    2. You then put one of those instances in a variable
    3. No matter what you do to those instances, you don’t change the fact of #2.

    It’s like putting your friend Sarah on a bike and then giving her Christina’s jacket. You haven’t changed the fact that Sarah is on the bike and Christina isn’t.

    • bterwijn@programming.devOP
      3·
      3 days ago

      Sure, but a lot of people incorrectly think the __eq__ and __hash__ are defined based on value not identity, as they are for many other types say float, str, or tuple. But for a class the default __eq__ method is x is y instead of x == y and also __hash__ is based on identity.

      Others assume that if you don’t define __hash__ for a class, that it doesn’t exists (like for list, set, or dict) so that a “TypeError: unhashable type: ‘Value’” exception is raised.

      I thought it was an interesting exercise to share, but maybe too simple for this audience, or people are just not aware of the basic steps that happen when adding and searching values in a set/dict. Try the same with type int:

      v1 = 1001
v2 = 1002
myset = {v1}
print(v1 in myset, end=' ')
v2 = 1001
print(v2 in myset, end=' ')
v1 = 1002
print(v1 in myset, end=' ')

      and you see a different output. To do the same with the Value class add methods:

      def __eq__(self, other):
    return self.value == other.value

def __hash__(self):
    return hash(self.value)
      • Daniel Quinn@lemmy.caEnglish
        1·
        4 days ago

        I think you’re fundamentally misunderstanding the above.

        In your first example, you change an attribute of an object. In your case you called it .value but could just as well have been called .jacket.

        In the second case you replaced one immutable object with another. You didn’t change the “value” attribute of 1002 to 1001. You replaced the entire object, 1002 with a new one: 1001.

        • bterwijn@programming.devOP
          1·
          3 days ago

          Yes indeed, the ‘int’ objects are stored and searched in the set based on their value, and the ‘Value’ objects are stored/searched based on their identity unless you define the above __eq__ and __hash__ methods which cause them to be stored/searched based on value too. This is a Python design decision and that’s the point of this exercise. The fact that ‘int’ is an immutable type and we are replacing isn’t relevant. Try replacing/reassigning the ‘Value’ objects after added __eq__ and __hash__, and you get the same result as for ‘int’. So the thing that really matters is how __eq__ and __hash__ are defined, and the default for a user-defined class is as stated in the “Explanation:” above.

          Maybe I should also show a class with __eq__ and __hash__ defined based on value, but then it gets a bit long. I’ll have to rethink this exercises so that the point comes across better as it now seems to confuse a lot of people based on the down-votes. Thanks for feedback anyway.