Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #74284

Re: Proposal: === and !=== operators

Show all headers | View raw

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

On 09Jul2014 09:17, Steven D'Aprano <steve@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@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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Proposal: === and !=== operators Steven D'Aprano <steve@pearwood.info> - 2014-07-09 07:00 +0000
  Re: Proposal: === and !=== operators Chris Angelico <rosuav@gmail.com> - 2014-07-09 17:21 +1000
    Re: Proposal: === and !=== operators Steven D'Aprano <steve@pearwood.info> - 2014-07-09 09:17 +0000
      Re: Proposal: === and !=== operators Rustom Mody <rustompmody@gmail.com> - 2014-07-09 09:20 -0700
      Re: Proposal: === and !=== operators Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-09 11:50 -0600
      Re: Proposal: === and !=== operators Cameron Simpson <cs@zip.com.au> - 2014-07-10 09:16 +1000
      Re: Proposal: === and !=== operators Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-07-12 13:54 +0200
        Re: Proposal: === and !=== operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-12 16:35 +0000
          Re: Proposal: === and !=== operators Chris Angelico <rosuav@gmail.com> - 2014-07-13 02:54 +1000
            Re: Proposal: === and !=== operators Roy Smith <roy@panix.com> - 2014-07-12 16:39 -0400
          Re: Proposal: === and !=== operators Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-07-12 20:14 +0200
            Re: Proposal: === and !=== operators Chris Angelico <rosuav@gmail.com> - 2014-07-13 09:01 +1000
              Re: Proposal: === and !=== operators Roy Smith <roy@panix.com> - 2014-07-12 19:06 -0400
                Re: Proposal: === and !=== operators Chris Angelico <rosuav@gmail.com> - 2014-07-13 09:15 +1000
            Re: Proposal: === and !=== operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-13 04:48 +0000
  Re: Proposal: === and !=== operators Cameron Simpson <cs@zip.com.au> - 2014-07-09 18:17 +1000
    Re: Proposal: === and !=== operators Steven D'Aprano <steve@pearwood.info> - 2014-07-09 09:02 +0000
      Re: Proposal: === and !=== operators Chris Angelico <rosuav@gmail.com> - 2014-07-09 19:23 +1000
  Re: Proposal: === and !=== operators Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-07-09 05:01 -0700
  Re: Proposal: === and !=== operators Roy Smith <roy@panix.com> - 2014-07-09 08:27 -0400
    Re: Proposal: === and !=== operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-09 12:48 +0000
      Re: Proposal: === and !=== operators Tim Chase <python.list@tim.thechases.com> - 2014-07-09 13:05 -0500
        Re: Proposal: === and !=== operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-10 01:10 +0000
      Re: Proposal: === and !=== operators Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-09 12:31 -0600
      Re: Proposal: === and !=== operators Roy Smith <roy@panix.com> - 2014-07-09 16:47 -0400
  Re: Proposal: === and !=== operators Ethan Furman <ethan@stoneleaf.us> - 2014-07-09 05:43 -0700
  Re: Proposal: === and !=== operators Robert Kern <robert.kern@gmail.com> - 2014-07-09 16:27 +0100
  Re: Proposal: === and !=== operators Alex Burke <alexjeffburke@gmail.com> - 2014-07-10 18:33 +0200
  Re: Proposal: === and !=== operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-12 03:30 +0000
    Re: Proposal: === and !=== operators Alan Bawden <alan@scooby-doo.csail.mit.edu> - 2014-07-12 01:07 -0400
      Re: Proposal: === and !=== operators Torsten Bronger <bronger@physik.rwth-aachen.de> - 2014-07-12 08:05 +0200
        Re: Proposal: === and !=== operators Torsten Bronger <bronger@physik.rwth-aachen.de> - 2014-07-12 08:14 +0200
      Re: Proposal: === and !=== operators Chris Angelico <rosuav@gmail.com> - 2014-07-12 16:06 +1000
      Re: Proposal: === and !=== operators Ethan Furman <ethan@stoneleaf.us> - 2014-07-11 23:11 -0700
      Re: Proposal: === and !=== operators Chris Angelico <rosuav@gmail.com> - 2014-07-12 16:39 +1000
        Re: Proposal: === and !=== operators Marko Rauhamaa <marko@pacujo.net> - 2014-07-12 10:06 +0300
      Re: Proposal: === and !=== operators Ethan Furman <ethan@stoneleaf.us> - 2014-07-11 23:53 -0700
      Re: Proposal: === and !=== operators Chris Angelico <rosuav@gmail.com> - 2014-07-12 17:25 +1000
      Re: Proposal: === and !=== operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-12 08:33 +0000

csiph-web