[Python-Dev] PyObject_RichCompareBool identity shortcut

[Guido van Rossum]

On Thu, Apr 28, 2011 at 4:40 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Pondering the NaN problem further, I think we can relatively easily
> argue that reflexive behaviour at the object level fits within the
> scope of IEEE754.

Now we're talking. :-)

> 1. IEEE754 is a value-based system, with a finite number of distinct
> NaN payloads
> 2. Python is an object-based system. In addition to their payload, NaN
> objects are further distinguished by their identity (infinite in
> theory, in practice limited by available memory).
> 3. We can still technically be conformant with IEEE754 even if we say
> that a given NaN object is equivalent to itself, but not to other NaN
> objects with the same payload.
>
> Unfortunately, this still doesn't play well with serialisation, which
> assumes that the identity of float objects doesn't matter:
>
>>>> import pickle
>>>> nan = float('nan')
>>>> x = [nan, nan]
>>>> x[0] is x[1]
> True
>>>> y = pickle.loads(pickle.dumps(x))
>>>> y
> [nan, nan]
>>>> y[0] is y[1]
> False
>
> Contrast that with the handling of lists, where identity is known to
> be significant:
>
>>>> x = [[]]*2
>>>> x[0] is x[1]
> True
>>>> y = pickle.loads(pickle.dumps(x))
>>>> y
> [[], []]
>>>> y[0] is y[1]
> True

Probably wouldn't kill us if fixed pickle to take object identity into
account for floats whose value is nan. (Fortunately for 3rd party
types pickle always preserves identity.)

> I'd say I've definitely come around to being +0 on the idea of making
> the float() and decimal.Decimal() __eq__ definitions reflexive, but
> doing so does have implications when it comes to the ability to
> accurately save and restore application state. It isn't as simple as
> just adding "if self is other: return True" to the respective __eq__
> implementations.

But it seems pickle is *already* broken, so that can't really be an
argument against the proposed change, right?

-- 
--Guido van Rossum (python.org/~guido)