Home Original page

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

Cameron Simpson cs at zip.com.au
Thu Jul 10 20:20:36 EDT 2014 
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?
More information about the Python-list mailing list