This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients alex, belopolsky, daniel.urban, mark.dickinson, rhettinger
Date 2011-05-16.17:26:38
SpamBayes Score 5.28603e-11
Marked as misclassified No
Message-id <>
In-reply-to <>
On Sat, May 14, 2011 at 2:50 PM, Mark Dickinson <> wrote:
> On the issue itself, I'm -1 on making comparisons with float('nan') raise: I don't see that there's a real problem here that needs solving.

I probably should have changed the title of this issue after making an
alternative proposal to make INVALID operations produce a warning:

For the case of nan ordering, this idea seemed to receive support on
the mailing list:

> Note that the current behaviour does *not* violate IEEE 754, since there's nothing anywhere
> in IEEE 754 that says that Python's < operation should raise for comparisons involving NaNs:
>  all that's said is that a conforming language should provide a number of comparison operations
> (without specifying how those operation should be spelt in the language in question), including
> both a < operation that's quiet (returning a false value for comparison with NaNs) and a <
> operation that signals on comparison with NaN.  There's nothing to indicate definitively which of
>  these two operations '<' should bind to in a language.

Yes, IEEE 754, provides little guidance to language designers, but why
would anyone want to treat
ordering of floats differently from ordering of decimals?

Traceback (most recent call last):
decimal.InvalidOperation: comparison involving NaN

> It *is* true that C chooses to bind '<' to the signalling version, but that doesn't automatically mean that we should do the same in Python.
> ----------
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
Date User Action Args
2011-05-16 17:26:39belopolskysetrecipients: + belopolsky, rhettinger, mark.dickinson, alex, daniel.urban
2011-05-16 17:26:38belopolskylinkissue11949 messages
2011-05-16 17:26:38belopolskycreate