[Python-Dev] PyObject_RichCompareBool identity shortcut

[Ethan Furman]

Mark Dickinson wrote:
> On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic <hrvoje.niksic at avl.com> wrote:
>> The other day I was surprised to learn this:
>>
>>>>> nan = float('nan')
>>>>> nan == nan
>> False
>>>>> [nan] == [nan]
>> True                  # also True in tuples, dicts, etc.
> 
> That one surprises me a bit too:  I knew we were using
> identity-then-equality checks for containment (nan in [nan]), but I
> hadn't realised identity-then-equality was also used for the
> item-by-item comparisons when comparing two lists.  It's defensible,
> though: [nan] == [nan] should presumably produce the same result as
> {nan} == {nan}, and the latter is a test that's arguably based on
> containment (for sets s and t, s == t if each element of s is in t,
> and vice versa).
> 
> I don't think any of this should change.  It seems to me that we've
> currently got something approaching the best approximation to
> consistency and sanity achievable, given the fundamental
> incompatibility of (1) nan breaking reflexivity of equality and (2)
> containment being based on equality.  That incompatibility is bound to
> create inconsistencies somewhere along the line.
> 
> Declaring that 'nan == nan' should be True seems attractive in theory,
> but I agree that it doesn't really seem like a realistic option in
> terms of backwards compatibility and compatibility with other
> mainstream languages.

Totally out of my depth, but what if the a NaN object was allowed to 
compare equal to itself, but different NaN objects still compared 
unequal?  If NaN was a singleton then the current behavior makes more 
sense, but since we get a new NaN with each instance creation is there 
really a good reason why the same NaN can't be equal to itself?

~Ethan~