On Sat, May 14, 2011 at 3:08 PM, Raymond Hettinger
<report@bugs.python.org> wrote:
..
>> Note that the current behaviour does *not* violate IEEE 754, ...
>
> I agree with Mark.

Do we really need a popular vote to determine what a published
standard does or does not require?

Section 7.2 of IEEE Std 754-2008 states:

"""
7.2 Invalid operation

The invalid operation exception is signaled if and only if there is no
usefully definable result. In these cases
the operands are invalid for the operation to be performed.
…

For operations producing no result in floating-point format, the
operations that signal the invalid operation exception are:
...
j)	comparison by way of unordered-signaling predicates listed in Table
5.2, when the operands are unordered
"""

Python comparison operators.

We can argue, of course about the proper mapping of IEEE 754 'INVALID'
exception to the available Python construct.  Arguably, a compliant
language can ignore INVALID exceptions, issue a warning while
returning result, or raise an exception and produce no result.  In a
post on Python ideas Mark argued that the ideal disposition of INVALID
is a ValueError:

"""
IMO, the ideal (ignoring backwards compatibility) would be to have
OverflowError / ZeroDivisionError / ValueError produced wherever
IEEE754 says that overflow / divide-by-zero / invalid-operation should
be signaled.
"""
http://mail.python.org/pipermail/python-ideas/2011-April/010106.html

If IEEE 754 compliance is a stated goal in Python design, it would
make very little sense to treat some cases of INVALID differently from
others.  If, however, IEEE 754 compliance is not a goal, we should
consider what is the most useful behavior.   On the mailing list, I
posted a challenge - review your code that will work differently if
nan ordering was disallowed and report whether that code does the
right thing for all kinds of float (including nan, inf and signed 0).
So far, I have not seen any responses to this.

My own experiment with the Python library itself, have revealed a bug
in the test suit.   This matches my prior experience: naive numeric
code usually produces nonsense results when nans are compared and
careful numeric code makes an effort to avoid comparing nans.

>  Am closing this feature request which is both ill-conceived and likely to cause more harm than good (possibly breaking code that currently does not fail).
>

My primary goal in posting this patch was to support the discussion on
python-ideas.  The patch was not intended to be applied as is.  At the
minimum, I would need to make nan < nan issue a deprecation warning
before turning it into an error.  If this is not an appropriate use of
the tracker - please propose an alternative.  Posting a patch on the
mailing list or outside of python.org seems to be a worse alternative.

>> the discussion about cleaning up test_math
>> (which I agree would be a good thing to do)
>> should probably go into another issue.
>
> I agree.

Why?  The issue in test_math is small enough that it can be fixed
without any discussion on the tracker.  If someone would want to
improve unittest based on this experience, this can indeed be handled
in a separate issue.  As long as the changes are limited to Lib/test,
I don't see what a separate issue will bring other than extra work.