operators
Reply-To:
In-Reply-To: <20140709231623.ga66...@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 <c...@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?
--
https://mail.python.org/mailman/listinfo/python-list
