[Python-Dev] Definition of equality check behavior (original) (raw)

Jordan Adler jordan.m.adler at gmail.com
Tue May 7 17:05:57 EDT 2019

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>

More information about the Python-Dev mailing list