On Fri, Jan 24, 2020 at 12:36:13PM +0300, Ivan Pozdeev via Python-Dev wrote:
> >I'm tempted to declare this implementation-defined behavior -- *implicit*
> >calls to __eq__ and __ne__ *may* be skipped if both sides are the same
> >object depending on the whim of the implementation.
>
> This cannot be an implementation detail because it changes the outcome of
> operations.
Guido didn't call it an implementation *detail* but implementation-
defined behaviour. And of course that implies that the outcome could be
different when using different implementations.
I'm pretty sure Guido understood the implication when he made that
comment.
The only thing I'm unsure of here is whether direct use of the `==` and
`!=` operators are included as "implicit calls" to the dunders. I
*think* I understand Guido's intention, but I'm not sure:
* x == y MUST call `__eq__`
* likewise x != y MUST call `__ne__`
* but compound objects such as lists and other collections MAY skip
calling `__eq__` (or `__eq__`) on their component parts.
> Without it, things like `math.nan in seq` would always return False.
There are other float NANs apart from math.nan.
If my arithmetic is correct, there are 9007199254740990 distinct float
NANs, or 0.05% of the 64-bit space. 4503599627370496 of those are quiet
NANs, and 4503599627370494 are signalling NANs.
In order words, even if you have
assert any(math.isnan(x) for x in values)
that does not mean that
math.nan in values
*should*, let alone *will*, return True.
> So it's not even an "optimization" but rather "behavior".
It is both. It is an optimization which also have an observable change
in behaviour.
--
Steven
_______________________________________________
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/NVZH7PKAYXOGMEBGWNVGF34FAKYJ24WB/
Code of Conduct: http://python.org/psf/codeofconduct/
