[Python-Dev] PyObject_RichCompareBool identity shortcut (original) (raw)

Alexander Belopolsky alexander.belopolsky at gmail.com
Wed Apr 27 18:05:46 CEST 2011

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.)

More information about the Python-Dev mailing list