Proposal: === and !=== operators
cs at zip.com.au
Thu Jul 10 01:16:23 CEST 2014
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
>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
>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:
... 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-==
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
More information about the Python-list