On Sat, May 14, 2011 at 2:50 PM, Mark Dickinson <report@bugs.python.org> 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:

http://mail.python.org/pipermail/python-ideas/2011-April/010101.html

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

http://mail.python.org/pipermail/python-ideas/2011-April/010102.html
http://mail.python.org/pipermail/python-ideas/2011-April/010103.html
http://mail.python.org/pipermail/python-ideas/2011-April/010104.html

> 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 <report@bugs.python.org>
> <http://bugs.python.org/issue11949>
> _______________________________________
>