On Mon, 2020-02-03 at 16:43 -0800, Larry Hastings wrote:
> On 2/3/20 3:07 PM, Sebastian Berg wrote:
> > That would mean adding `operator.equivalent(a, b) -> bool` which
> > would
> > allow float to override the result and let
> > `operator.equivalent_value(float("NaN"), float("NaN))` return True;
> > luckily very few types would actually override the operation.
>
> You misunderstand what's going on here. Python deliberately makes
> float('NaN') != float('NaN'), and in fact there's special code to
> ensure that behavior. Why? Because it's mandated by the IEEE 754
> floating-point standard.
>
> > https://en.wikipedia.org/wiki/NaN#Comparison_with_NaN
> >
>
> This bizarre behavior is often exploited by people exploring the
> murkier corners of Python's behavior. Changing it is (sadly) not
> viable.
>
Of course it is not, I am not saying that it should be changed. What I
mainly meant is that in this discussion there was always the talk about
two distinct, slightly different operations:
1. `==` has of course the logic `NaN == NaN -> False`
2. `PyObject_RichCompareBool(a, b, Py_EQ)` was argued to have a useful
logic of `a is b or a == b`. And I argued that you could define:
def operator.identical(a, b):
res = a is b or a == b
assert type(res) is bool # arrays have unclear logic
return res
to "bless" it as its own desired logic when dealing with containers
(mainly).
And that making that distinction on the language level would be
a(possibly ugly) resolution of the problem.
Only `identical` is actually always allowed to use the `is` shortcut.
Now, for all practical purposes "identical" is maybe already correctly
defined by `a is b or bool(a == b)` (NaN being the largest
inconsistency, since NaN is not a singleton).
Along that line, I could argue that `PyObject_RichCompareBool` is
actually incorrectly implemented and it should be replaced with a new
`PyObject_Identical` in most places where it is used.
Once you get to the point where you accept the existance of `identical`
as a distinct operation, allowing `identical(NaN, NaN)` to be always
true *can* make sense, and resolves current inconsistencies w.r.t.
containers and NaNs.
- Sebastian
>
> /arry
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/GOJNWAJSFHBSCCJD2RYWNDRN7RJHYWD3/
> Code of Conduct: http://python.org/psf/codeofconduct/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CQIATNXMQW3GKZMAKF22GD6TVAO2X5KK/ Code of Conduct: http://python.org/psf/codeofconduct/
