[Python-Dev] PyObject_RichCompareBool identity shortcut

[Alexander Belopolsky]

On Wed, Apr 27, 2011 at 11:31 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
..
> Backing away from having float and decimal.Decimal respect the IEEE754
> notion of NaN inequality at this late stage of the game seems like one
> for the "too hard" basket.

Why?  float('nan') has always been in the use-at-your-own-risk
territory despite recent efforts to support it across Python
platforms.   I cannot speak about decimal.Decimal (and decimal is a
different story because it is tied to a particular standard), but the
only use of non-reflexifity for float nans I've seen was use of x != x
instead of math.isnan(x).

> It also wouldn't achieve much, since we
> want the builtin containers to preserve their invariants even for 3rd
> party types with a non-reflexive notion of equality.

These are orthogonal issues.   A third party type that plays with
__eq__ and other basic operations can easily break stdlib algorithms
no matter what we do.  Therefore it is important to document the
properties of the types that each algorithm relies on.  It is more
important, however that stdlib types do not break 3rd party's
algorithms.   I don't think I've ever seen a third party type that
deliberately defines a non-reflexive __eq__ except as a side effect of
using float attributes or C float members in the underlying structure.
 (Yes, decimal is a counter-example, but this is a very special case.)