[Python-Dev] Definition of equality check behavior

[Ivan Levkivskyi]

On Tue, 7 May 2019 at 22:31, 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
> '==').
>

I don't think there is a chance this can be changed at runtime. OTOH, mypy
has a (pretty recent, so better use master) flag --strict-equality that
uses some heuristics to detect suspicious comparisons, identity checks, and
container checks (all of these may return False at runtime while some
people want them to be an error, e.g. b'abc' == 'abc', '1' in [1, 2, 3],
etc).

--
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190508/cd7df324/attachment.html>