This goes against "there's only one way to do it" and overriding equality and hashing is niche enough that I don't think it warrants having two ways of doing it (because you can't drop overriding __eq__/__hash__ due to backwards-compatibility concerns). On Wed, May 8, 2019 at 9:50 AM Phillip Cloud <cpcloud@gmail.com> wrote:

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/

This goes against "there's only one way to do it" and overriding equality and hashing is niche enough that I don't think it warrants having two ways of doing it (because you can't drop overriding __eq__/__hash__ due to backwards-compatibility concerns). On Wed, May 8, 2019 at 9:50 AM Phillip Cloud <cpcloud@gmail.com> wrote:

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/