[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Definition of equality check behavior

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
<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>

> 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>