Proposal: === and !=== operators

Steven D'Aprano steve+comp.lang.python at
Sat Jul 12 05:30:48 CEST 2014

Thanks to everyone who has commented. Some responses:

* I was completely mistaken about == enforcing the rule 
  that __eq__ returns True or False. I have no idea where
  I got that idea from, sorry for the noise.

* I disagree that having two equals operators, == and ===, 
  would be confusing. The Javascript/PHP model doesn't apply:

  - In Javascript and PHP, the shorter, more attractive
    version == does the wrong thing and is harmful, hence
    everyone needs to learn about === immediately.
  - In my proposal, the shorter, more attractive version 
    == does what everyone already assumes == will do. It's
    only specialists who need to learn about === .

* But having said that, I find myself trying to solve a problem
  reported by Anders which I do not understand, cannot replicate,
  and although I'm willing to give him the good faith benefit of 
  the doubt, I find myself less and less convinced that the 
  problem is what he thinks it is.

To be specific, the one concrete piece of code Anders has posted is a 
completely generic "detect changes" function which he claims is broken by 
the presence of NANs. That may be, but his code is not runnable (it uses 
undefined methods that could do anything) so cannot be tested, and I 
cannot replicate his problem.

NANs or no NANs, a generic "detect changes" function already fails to 
work in some circumstances:

py> data = [1, 2.0, 3.0, 4.0]
py> old = data[:]
py> old == data  # No changes made yet, should return True
py> data[0] = 1.0  # Change of type.
py> old == data  # Should return False

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
py> data[3] = 104.0
py> old == data  # Should return False

The only time it may fail, for some definition of "fail", is when the NAN 
is replaced by another NAN of the same payload but different identity. 
But I still fail to understand Ander's use-case here, how a NAN might be 
replaced by another NAN, or why he wants to compare two different NANs as 

Since I do not understand Ander's problem, I cannot hope to solve it. So 
I withdraw my suggestion. Thanks to everyone who listened.


More information about the Python-list mailing list