A number of libraries override the equality operator (__eq__) in such a way that it returns an object that isn't a Python bool. This all but precludes making these objects hashable, even though there's nothing in principle that prevents them from being so.
The main use case I have in mind is an expression DSL that returns another expression when its __eq__ method is called (sqlalchemy is a good example of such a DSL). In such DSLs you often want to use expressions as keys in dict. You *can* use them as keys, but the code that does is only reliable insofar as it can guarantee that the expressions in the dict are identical (in the sense of a pointer) to the values you're going to later use for lookup. After thinking about this for a bit, I'd like to understand whether it's reasonable to propose a new method __hash_eq__ that would be used during dict key comparisons (in lookdict). This new method would allow an object to override __eq__ *and* be hashable, by defining __hash_eq__. __hash_eq__ would only be allowed to return a bool, unlike __eq__. Regarding backwards compatibility, __hash_eq__ would be defined by default to be equivalent to __eq__. I haven't thought about other standard library mappings like OrderedDict yet, and it's entirely possible that such considerations would kill this idea. I did some googling before writing this up, and I couldn't find anything that proposed anything like this but perhaps my google skills are lacking. If there's a history here that I'm missing I'm happy to learn more about it.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
