[Python-Dev] Definition of equality check behavior

[Jordan Adler]

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/20190507/92adb1b6/attachment.html>