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

[MRAB]

On 2012-10-12 19:42, Joshua Landau wrote:
> On 11 October 2012 02:20, Steven D'Aprano <steve at pearwood.info
> <mailto:steve at pearwood.info>> wrote:
>
>     On 11/10/12 09:05, Joshua Landau wrote:
>
>         After re-re-reading this thread, it turns out one *(1)* post and two
>         *(2)* answers
>
>         to that post have covered a topic very similar to the one I have
>         raised.
>         All of the others, to my understanding, do not dwell over the fact
>         that *float("nan") is not float("nan")* .
>
>
>     That's no different from any other float.
>
>     py> float('nan') is float('nan')
>     False
>     py> float('1.5') is float('1.5')
>     False
>
>     Floats are not interned or cached, although of course interning is
>     implementation dependent and this is subject to change without notice.
>
>     For that matter, it's true of *nearly all builtins* in Python. The
>     exceptions being bool(obj) which returns one of two fixed instances,
>     and int() and str(), where *some* but not all instances are cached.
>
>  >>> float(1.5) is float(1.5)
> True

It re-uses an immutable literal:

 >>> 1.5 is 1.5
True
 >>> "1.5" is "1.5"
True

and 'float' returns its argument if it's already a float:

 >>> float(1.5) is 1.5
True

Therefore:

 >>> float(1.5) is float(1.5)
True

But apart from that, when a new object is created, it doesn't check
whether it's identical to another, except in certain cases such as ints
in a limited range:

 >>> float("1.5") is float("1.5")
False
 >>> float("1.5") is 1.5
False
 >>> int("1") is 1
True

And it's an implementation-specific behaviour.

>  >>> float("1.5") is float("1.5")
> False
>
> Confusing re-use of identity strikes again. Can anyone care to explain
> what causes this? I understand float(1.5) is likely to return the
> inputted float, but that's as far as I can reason.
>
> What I was saying, though, is that all other posts assumed equality
> between two different NaNs should be the same as identity between a NaN
> and itself. This is what I'm really asking about, I guess.
>
>         Response 1:
>         This implies that you want to differentiate between -0.0 and
>         +0.0. That is
>         bad.
>
>         My response:
>         Why would I want to do that?
>
>
>     If you are doing numeric work, you *should* differentiate between -0.0
>     and 0.0. That's why the IEEE 754 standard mandates a -0.0.
>
>     Both -0.0 and 0.0 compare equal, but they can be distinguished (although
>     doing so is tricky in Python). The reason for distinguishing them is to
>     distinguish between underflow to zero from positive or negative values.
>     E.g. log(x) should return -infinity if x underflows from a positive
>     value,
>     and a NaN if x underflows from a negative.
>
>
> Interesting.
>
> Can you give me a more explicit example? When would you not *want*
> f(-0.0) to always return the result of f(0.0)? [aka, for -0.0 to warp
> into 0.0 on creation]
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>