RetroSearch Browse

Tue May 18 23:24:50 EDT 2004 · https://mail.python.org/pipermail/python-dev/2004-May/044904.html

[Armin Rigo]
> ...
> Note that as discussed below the following behavior is *expected* and in
> accordance with standards:
>
> >>> float('nan') is float('nan')
> False

That result simply isn't defined, even on platforms where float('nan')
doesn't blow up:  floats are immutable objects, and outside of interning
strings, Python doesn't define anything about the identity of immutable
objects returned from computation.

> >>> float('nan') == float('nan')
> False                             # not the same object

The one is a platform-dependent crapshoot, and again even on platforms where
float('nan') doesn't blow up.  In current CVS HEAD, Michael made it much
more *likely* to return False than in any Python released to date, but
there's still no guarantee.  For example, even with current CVS, it returns
True if compiled with MSVC 6, but False if compiled with MSVC 7.1.  Python
simply doesn't define anything about behavior in the presence of NaNs,
infinities or signed zeroes (neither as floats nor as string representations
(like 'nan')).

> Unless there are serious objections I suggest to (i.e. I plan to) remove
> the short-cut in PyObject_RichCompareBool() -- performance is probably
> not an issue here -- and then review all built-in comparison methods and
> make sure that they return "equal" for identical objects.

If your recursive dict compares work OK then, fine by me.  The exact details
of comparison semantics have always been muddy, and I expect always will be
(the combination of backward compatibility hacks and new features makes
comparison reality as complicated as the code implementing it -- that's some
of the most complicated stuff in the entire codebase).

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-May/044904.html below:

[Python-Dev] cmp(x,x)