Proposal: === and !=== operators

[Cameron Simpson]

TL;DR: I've got an alternative proposal at the bottom of this message.

On 09Jul2014 09:17, Steven D'Aprano <steve at pearwood.info> wrote:
>On Wed, 09 Jul 2014 17:21:20 +1000, Chris Angelico wrote:
>> 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.

But most people also expect float addition to act as though they were Decimals.

I think the real problem here is that "float" is IEEE float and this isn't what 
a naive user imagines.

>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.)

I agree people should have a noncumbersome way to get particular behaviours.

I have a (possibly ghastly) alternative suggestion, lower down.

>> 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.

Um, I disagree. And I also think that === in Python being different to (say) 
PHP === or JS === will further confuse things, since they are spelt the same.

At the moment Python has "is", which is very simple in concept, and ==, which 
is also conceptually simple (equal values, for the relevant values in the 
object). I agree that "is" not implying "==" is confusing when it happens, but 
that is only for a few types. Regrettably, float is heavily used.

>> 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.

I think Ian Kelly has pointed out that this already works, and that therefore 
Andres' problem may be more comoplicated and not fixed by your proposal.

I think, based entirely on my subjective memory of discussion rates on 
python-list and doubtless influences by not hanging our in numeric computing 
lists, that float not being a plain decimal construct causes more confusion and 
surprise.

>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.

I have (hazy) memories of seeing plenty of little pseudo-informative magazine 
articles discussing this kind of thing for PHP etc. The very presence of the 
extra very similar operator spawns clarification articles.

[...]
>> 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.

Ok, here is my alternative proposal: dynamic float behaviour selection.

Consider this code snippet:

   with float.behaviour(nan_eq=True):
       ... code here ...

This sets a thread-local behaviour flag on the entire float type and undoes it 
on exit from the context.

This has the following advantages:

   - it is very easy to use, and makes plain that this particular chunk of code has special rules

   - it makes NaN == behaviour as requested in a particular window

   - it can wrap all code called inside the suite

   - because it is thread local it doesn't asynchronously affect other running code

   - it doesn't introduce a new operator
   
   - it affects a tightly constrainted behaviour, and can obviously be extended to other special cases if they arise

The downside is that it could break code depending on NaN being nonreflexive 
_if_ that code is called within the suite.

Personally, I would take this over a new and only-subtly-different-from-== 
"===" operator.

Cheers,
Cameron Simpson <cs at zip.com.au>

Check out Doohan's rear/all wheel slide in the French GP.  Oh yeah.
"I was just mucking around.  I won't do that again." - Mick Doohan