On Wed, Jul 9, 2014 at 3:17 AM, Steven D'Aprano <st...@pearwood.info> wrote:
> 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).
Well, if we're talking about *lists*, then the comparison operator
already compares identity of individual elements:
>>> nan = float('nan')
>>> l1 = [1.0, 2.0, nan, 4.0]
>>> l2 = [1.0, 2.0, nan, 4.0]
>>> l1 == l2
True
So the comparison "x is y or x == y" could also be written "[x] ==
[y]", without requiring any changes to the language.
I suspect that just adding identity comparison is not sufficient to
solve Anders' problem, though.
> 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
The only reason this fails is because the two nans are neither
identical nor equal. The proposed == semantics would also fail here.
--
https://mail.python.org/mailman/listinfo/python-list
