context manager based alternative to Re: Proposal: === and !===
cs at zip.com.au
Fri Jul 11 02:20:36 CEST 2014
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
Here's an alternative proposal that doesn't involve a new operator.
Consider this code snippet:
... 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.
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