Proposal: === and !=== operators

Chris Angelico rosuav at
Sat Jul 12 08:06:51 CEST 2014

On Sat, Jul 12, 2014 at 3:07 PM, Alan Bawden
<alan at> wrote:
> Steven D'Aprano <steve+comp.lang.python at> writes:
>> But perhaps we only care about changes in value, not type. NAN or no NAN,
>> list equality works fine:
>> py> data = [1.0, 2.0, float('nan'), 4.0]
>> py> old = data[:]
>> py> old == data  # No changes made yet, should return True
>> True
> You lost me right here.  If list equality is determined by comparing
> lists element-by-element, and the second element of old is _not_ equal
> to the second element of data, then why should old and data be equal?
> In fact, I find myself puzzled about exactly how list equality is
> actually defined.

In the Python 3 docs, it's made a bit clearer, at least as regards the
'in' and 'not in' operators: it's an identity check followed by an
equality check - "x is y or x == y". The same comparison is done for
equality, although it's not strictly described there (at least, I
couldn't find it). There are a lot of these sorts of corner cases that
aren't made really clear in the docs, because the verbosity would be
more of a problem than the omission - I consider them to be like "The
land continues to burn" on Obsidian Fireheart [1] or the reminder text
on Madness [2]; if you go to the Magic: The Gathering Comprehensive
Rulebook, you can find the exact "code-accurate" details on how either
one works, but that takes several pages of verbiage, and it's much
better to just say "you may cast it for its madness cost instead of
putting it into your graveyard".

For the most part, the identity check is a pure optimization. Most
Python objects compare equal to themselves. It only VERY occasionally
matters (like when there's a NaN in your list), and for those cases,
you have the interactive interpreter to try things at.


[2] eg

More information about the Python-list mailing list