Hi Collin, > From the documentation of object.__hash__(self) [1]: > > The only required property is that objects which compare equal > have the same hash value; it is advised to mix together the hash > values of the components of the object that also play a part in > comparison of objects by packing them into a tuple and hashing > the tuple.
Yup, the same is true in all programming languages (C, Java, etc.). > Right now we use the following to compute the hash in GLModule: > > result = hash(self.name) ^ hash(self.patched) > > The way that the documentation recommends writing this: > > result = hash((self.name, self.patched)) Both of these hash code are good. It is good if the hash function is not symmetric in the properties: we do *not* want that (a,b) and (b,a) produce the same has code, because it would slow down hash table lookups. But since self.patched is boolean, the first formula is not symmetric. > But I believe the 'patched' boolean should not be involved in > computing the hash. I agree: The 'patched' property is inferred from the files on disk when a GLModule object is created. Once a GLModule with a given name has been created, no second one with the same name will be created. Applied. Thanks! Bruno
