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

Cameron Simpson cs at
Sat Jul 12 00:37:55 CEST 2014

On 11Jul2014 14:37, Chris Angelico <rosuav at> wrote:
>On Fri, Jul 11, 2014 at 11:17 AM, Roy Smith <roy at> wrote:
>> In article <mailman.11744.1405038048.18130.python-list at>,
>>  Cameron Simpson <cs at> 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

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 

I agree this is a risk.

As a matter of interest, in what scenarios do people typically rely on 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

If you mean:

   float x, y;
   if (x == y) {

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?


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

Can you elaborate on this statement please?

Cameron Simpson <cs at>

Automobile: device used to drive slower than motorcycles.

More information about the Python-list mailing list