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/

Reply via email to