[Python-ideas] checking for identity before comparing built-in objects

[Mike Graham]

On Tue, Oct 9, 2012 at 9:14 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On 10/10/12 09:13, Joshua Landau wrote:
>>
>> Just a curiosity here (as I can guess of plausible reasons myself, so
>> there
>> probably are some official stances).
>>
>> Is there a reason NaNs are not instances of NaN class?
>
>
> Because that would complicate Python's using floats for absolutely no
> benefit.
> Instead of float operations always returning a float, they would have to
> return
> a float or a NAN. To check for a valid floating point instance, instead of
> saying:
>
> isinstance(x, float)
>
> you would have to say:
>
> isinstance(x, (float, NAN))
>
> And what about infinities, denorm numbers, and negative zero? Do they get
> dedicated classes too?
>
> And what is the point of this added complexity? Nothing.
>
> You *still* have the rule that "x == x for all x, except for NANs". The
> only difference is that "NANs" now means "instances of NAN class" rather
> than
> "NAN floats" (and Decimals). Working with IEEE 754 floats is now far more of
> a nuisance because some valid floating point values aren't floats but have a
> different class, but nothing meaningful is different.
>
>
>
>> Then x == x would be True (as they want), but [this NaN] == [that NaN]
>> would be False, as expected.
>
>
> Making NANs their own class wouldn't give you that. If we wanted that
> behaviour, we could have it without introducing a NAN class: just change the
> list __eq__ method to scan the list for a NAN using math.isnan before
> checking
> whether the lists were identical.
>
> But that would defeat the purpose of the identity check (an optimization to
> avoid scanning the list)! Replacing math.isnan with isinstance doesn't
> change
> that.
>
>
>
>> I guess that raises the question about why x == x but sqrt(-1) !=
>> sqrt(-1),
>
>
> That question has already been raised, and answered, repeatedly in this
> thread.
>
>
>
>> but it seems a lot less of a big deal than all of the exceptions with
>> container equalities.
>
>
> Container equalities are not a big deal. I'm not sure what problem you think
> you are solving.
>
> --
> Steven

I'm sometimes surprised at the creativity and passion behind solutions
to this issue.

I've been a Python user for some years now, including time dealing
with stuff like numpy where you're fairly likely to run into NaNs.
I've been an active member of several support communities where I can
confidently say I have encountered tens of thousands of Python
questions. Not once can I recall ever having or seeing anyone have an
actual problem that I had or someone else had due to the way Python
handles NaN. As far as I can tell, it works _perfectly_.

I appreciate the aesthetic concerns, but I really wish someone would
explain to me what's actually broken and in need of fixing.

Mike