Proposal: === and !=== operators

[Steven D'Aprano]

On Wed, 09 Jul 2014 17:21:20 +1000, Chris Angelico wrote:

> On Wed, Jul 9, 2014 at 5:00 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
>> Thoughts? Comments?
> 
> First thought: It will just add confusion. Currently, there are small
> pockets of confusion surrounding the few cases where something's
> non-reflexive, and there are occasional threads on the subject, like we
> have now. 

It's a reoccurring issue that keeps coming up over and over again. Most 
people have no need of NANs, and want them to behave like "normal" 
objects. I'm sympathetic to this idea.

Whenever this comes up, no-one has suggested any non-reflexive values 
other than NANs, SQL NUL, and "Always Compares Unequal", which I suspect 
is more of a toy than an actual useful example. So there are *very, very* 
few people who actually need NANs. 

(But those who do ought to be able to easily get it.)



> Adding another pair of equality operators will mean that
> everyone has to think "Do I want == or ===?", 

I don't think so. Nearly everyone will just use ==, those who want === 
will know they need it.


> and we just need to look
> at PHP and ECMAScript to see what happens - people pick the wrong
> operator and have no end of subtle problems. 

People are already having problems, just listen to Anders. He's 
(apparently) not doing NAN-aware computations on his data, he just wants 
to be able to do something like

this_list_of_floats == that_list_of_floats

without NANs screwing it up. But by the same token, if I want to use NANs 
the way they're supposed to be used, I should still be able to use an 
equals operator (rather than a function or method).


> There will be blog posts
> around saying "always use === in Python", or "never use === in Python",

I doubt that this would even come into the radar of most bloggers.


> and everyone will get confused about how Python's === is similar to
> and/or different from ECMAScript's and/or PHP's, 

Like we get confused over how == is different from Javascript's and 
PHP's? :-)



> and ultimately, the
> only people who win out will be those who get paid to write blog posts.
> 
> I think this is a big fat YAGNI. The two operators will differ in so few
> situations that you may as well just define a few cases as "x is y or x
> == y" instead of creating thew new operator; 

But the problem is, most people will need to us "x is y or x == y" nearly 
everywhere! And that doesn't help with containers:

py> alist = [1.0, 2, float('NAN'), 4]
py> blist = [1, 2.0, float('nan'), 4]
py> alist is blist or alist == blist
False


There ought to be a simple way for people to get alist == blist, while 
still allowing IEEE-754 aware code to work.


> because really, that's all
> that's happening here. (And the Py3 docs now use that kind of notation
> to describe 'in'.) If you want fuzzy logic or three-valued truth or
> anything, you probably know the types of the things you're comparing, so
> it should be safe to use a method.

Ah, forget the fuzzy logic, I was dreaming.


-- 
Steven