Proposal: === and !=== operators

[Devin Jeanpierre]

On Wed, Jul 9, 2014 at 12:00 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> At the moment, Python has two (in)equality operators, == and != which
> call __eq__ and __ne__ methods. Some problems with those:
>
>
> * Many people expect == to always be reflexive (that is, x == x for
>   every x) but classes which customise __eq__ may not be.
>
> * The == operator requires __eq__ to return True or False
>   (or NotImplemented) and raises TypeError if it doesn't, which
>   makes it impossible to use == with (say) three-valued or fuzzy
>   logic.

Counter-proposal: The second use case doesn't matter that much, and
can be added to == without breaking backwards compatibility
meaningfully. The first case is covered by all sorts of things, but
I'd suggest that the most meaningful way in which nan "is the same as"
nan is that they both behave the same, as objects.

The Python "is" operator returns True when two objects are identical.
Is it a great leap to guarantee, in Python, that equivalent immutable
objects are always identical? Then float('nan') is float('nan') should
always return True. We already implicitly allow that a Python
implementation may choose to do this (e.g. small integers are cached),
but it isn't so hard to guarantee it. (You don't even have to cache
anything. PyPy makes things is-identical even when they are behind the
scenes different objects in memory, IIRC.)

See also http://wiki.ecmascript.org/doku.php?id=harmony:egal , which
is a similar proposal for ES6.

-- Devin