[Python-Dev] Definition of equality check behavior

[Max Vogler]

Thanks for starting this discussion and addressing my issue, Jordan.

I would like to clarify the intentions behind my original issue
<https://github.com/PythonCharmers/python-future/issues/432>: It does not
concern coercion in Python's __eq__. Instead, the issue concerns the return
of False instead of NotImplemented in future.types.newstr.__eq__. As a
result, in special cases this breaks the symmetry of equality.

Also, please be aware of the difference between NotImplemented (a singleton
that is used as indicator for an unimplemented equality operation) and
NotImplementedError
<https://docs.python.org/3/library/exceptions.html#NotImplementedError>, a
RuntimeError used for example in abstract classes. To quote from the docs:
> NotImplementedError and NotImplemented are not interchangeable, even
though they have similar names and purposes.

On Tue, May 7, 2019 at 11:06 PM Jordan Adler <jordan.m.adler at gmail.com>
wrote:

> Hey folks!
>
> Through the course of work on the future polyfills
> <https://github.com/PythonCharmers/python-future/issues/432> that mimic
> the behavior of Py3 builtins across versions of Python, we've discovered
> that the equality check behavior of at least some builtin types do not
> match the documented core data model
> <https://docs.python.org/3/reference/datamodel.html#object.__eq__>.
>
> Specifically, a comparison between a primitive (int, str, float were
> tested) and an object of a different type always return False, instead of
> raising a NotImplementedError.  Consider `1 == '1'` as a test case.
>
> Should the data model be adjusted to declare that primitive types are
> expected to fallback to False, or should the cpython primitive type's
> __eq__ implementation fallback to raise NotImplementedError?
>
> Reasonable people could disagree about the right approach, but my distaste
> for silent failures leads me to recommend that the implementation be
> adjusted to return NotImplementedError as a fallback, and to document that
> the operands should not be coerced to the same type prior to comparison
> (enforcing a stricter equality check). This will of course require a
> deprecation protocol.
>
> Alternatively some new equality operator could be used to specify the
> level of coercion/type checking desired (currently Python has 'is' and
> '==').
>
> Jordan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190508/0cb7e137/attachment.html>