<div dir="ltr">Hey folks!<div><br><div>Through the course of <a href="https://github.com/PythonCharmers/python-future/issues/432">work on the future polyfills</a> 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 <a href="https://docs.python.org/3/reference/datamodel.html#object.__eq__">documented core data model</a>.</div></div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Reasonable people could disagree about the right approach, but my distaste for silent failures leads me to recommend t<span style="font-size:0.875rem">hat 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). </span><span style="font-size:0.875rem">This will of course require a deprecation protocol.</span><span style="font-size:0.875rem"> </span></div><div><span style="font-size:0.875rem"><br></span></div><div><span style="font-size:0.875rem">Alternatively some new equality operator could be used to specify the level of coercion/type checking desired (currently Python has 'is' and '==').</span></div><div><br></div><div><span style="font-size:0.875rem">Jordan</span></div></div>