(original) (raw)

On Tue, 7 May 2019 at 22:31, Jordan Adler <jordan.m.adler@gmail.com> wrote:

Hey folks!

Through the course of work on the future polyfills 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.

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