TL;DR: I've got an alternative proposal at the bottom of this message.
On 09Jul2014 09:17, Steven D'Aprano <st...@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 <c...@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
--
https://mail.python.org/mailman/listinfo/python-list
