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

Robert Kern robert.kern at gmail.com
Thu Apr 28 17:52:02 CEST 2011

On 4/27/11 11:54 PM, Guido van Rossum wrote:

On Wed, Apr 27, 2011 at 9:25 PM, Robert Kern<robert.kern at gmail.com> wrote:

On 2011-04-27 23:01 , Guido van Rossum wrote:

And I wouldn't want to change that. It sounds like NumPy wouldn't be much affected if we were to change this (which I'm not saying we would).

Well, I didn't say that. If Python changed its behavior for (float('nan') == float('nan')), we'd have to seriously consider some changes. Ah, but I'm not proposing anything of the sort! float('nan') returns a new object each time and two NaNs that are not the same object will still follow the IEEE std. It's just when comparing a NaN-valued object to itself (i.e. the same object) that I would consider following the lead of Python's collections.

Ah, I see!

We do like to keep some amount of correspondence with Python semantics. In particular, we like our scalar types that match Python types to work as close to the Python type as possible. We have the np.float64 type, which represents a C double scalar and corresponds to a Python float. It is used when a single item is indexed out of a float64 array. We even subclass from the Python float type to help working with libraries that may not know about numpy:

[~] |5> import numpy as np [~] |6> nan = np.array([1.0, 2.0, float('nan')])[2] [~] |7> nan == nan False Yeah, this is where things might change, because it is the same object left and right. [~] |8> type(nan) numpy.float64 [~] |9> type(nan).mro() [numpy.float64, numpy.floating, numpy.inexact, numpy.number, numpy.generic, float, object]

If the Python float type changes behavior, we'd have to consider whether to keep that for np.float64 or change it to match the usual C semantics used elsewhere. So there would be a dilemma. Not necessarily the most nerve-wracking one, but a dilemma nonetheless. Given what I just said, would it still be a dilemma? Maybe a smaller one?

Smaller, certainly. But now it's a trilemma. :-)

  1. Have just np.float64 and np.complex128 scalars follow the Python float semantics since they subclass Python float and complex, respectively.
  2. Have all np.float* and np.complex* scalars follow the Python float semantics.
  3. Keep the current IEEE-754 semantics for all float scalar types.

-- Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

More information about the Python-Dev mailing list