context manager based alternative to Re: Proposal: === and !===

[Cameron Simpson]

On 11Jul2014 14:37, Chris Angelico <rosuav at gmail.com> wrote:
>On Fri, Jul 11, 2014 at 11:17 AM, Roy Smith <roy at panix.com> wrote:
>> In article <mailman.11744.1405038048.18130.python-list at python.org>,
>>  Cameron Simpson <cs at zip.com.au> wrote:
[... context manager changing NaN comparisons ...]
>I'm a bit wary of anything that makes a global, even if temporary,
>change to comparisons' behaviours. What happens if, deep in a call
>tree, something utterly unrelated happens to do a comparison of this
>nature?

Weirdness, possibly very subtle weirdness. Possibly harmless weirdness. It 
reall depends on what reliance the unrelated (but called) code has on 
nonreflexivity. I would think most code almost never depends on it.

What happens to nontrivial geometric proofs if you switch "parallel" from 
"lines never meet" to "lines meet at infinity"? Do the proofs become invalid?  
(Surely yes in some circumstances.) How do geometers know when validating 
proofs?

I agree this is a risk.

As a matter of interest, in what scenarios do people typically rely on NaN != 
NaN?

The OP (Anders) broadly wanted to be able to compare datasets that included 
real python float NaNs and not have otherwise identical datasets claim to 
differ because they had NaNs (possible the same NaN instance) in the same spot.  

Also, he wasn't doing "blind" data comparison - he still needed to use real 
floats because his code did arithmetic with them, and therefore was not helped 
by suggestions of "casting" floats to integers (bytewise the same in memory) to 
sidestep the NaN specialness.

>Does C-level code have to check this flag before comparing
>nans,

If you mean:

   float x, y;
   [...]
   if (x == y) {
     action...
   }

then no.

>or is this applicable only to the Python float objects and only
>when compared in Python?

The former but not the latter, in my mind. Comparing Python float objects 
should obey the rule, whether in pure Python or extensions using a PyFloat. But 
I'd hope they get that for free by indirecting through PyFloat's methods.

>Is isnan() still usable?

Yes.

>(Consider that x!=x == math.isnan(x) normally.)

Can you elaborate on this statement please?

Cheers,
Cameron Simpson <cs at zip.com.au>

Automobile: device used to drive slower than motorcycles.