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

[Cameron Simpson]

operators
Reply-To:
In-Reply-To: <20140709231623.GA66358 at cskk.homeip.net>

I posted this the other day and haven't seen a response, not even a scathing 
rejection...

Here's an alternative proposal that doesn't involve a new operator.

Consider this code snippet:

   with float.behaviour(nan_eq=True):
       ... code here ...

This is intended to set a thread-local behaviour flag on the entire float type 
and undo it on exit from the context.

This has the following advantages:

   - it is very easy to use, and makes plain that this particular chunk of code has special rules

   - it makes NaN == behave as requested in a particular window

   - it effectively wraps all code called inside the suite

   - because it is thread local it doesn't asynchronously affect other running code

   - it doesn't introduce a new operator

   - it affects a tightly constrainted behaviour, and can obviously be extended to other special cases if they arise, for example to only make the same flavour of NaN compare equal

   - if the special Nan != Nan checks occur only in the Nan instances themselves (eg by monkey patching __eq__ onto one) then it should not affect performance outside the NaN instances

The downside is that it could break code depending on NaN being 
nonreflexive _if_ that code is called within the suite.

Personally, I would take this over a new and only-subtly-different-from-== 
"===" operator. It also seems to give more control to the programmer, in that 
they can set the domain in which the behaviour obtains.

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

Q: How many user support people does it take to change a light bulb?
A: We have an exact copy of the light bulb here and it seems to be
    working fine.  Can you tell me what kind of system you have?