Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #74333 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  context manager based alternative to Re: Proposal: === and !=== Cameron Simpson <cs@zip.com.au> - 2014-07-11 10:20 +1000
    Re: context manager based alternative to Re: Proposal: === and !=== Roy Smith <roy@panix.com> - 2014-07-10 21:17 -0400
      Re: context manager based alternative to Re: Proposal: === and !=== Chris Angelico <rosuav@gmail.com> - 2014-07-11 14:37 +1000

#74333 — context manager based alternative to Re: Proposal: === and !===

operators
Reply-To:
In-Reply-To: <20140709231623.GA66358@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@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?

[toc] | [next] | [standalone]

#74335

In article <mailman.11744.1405038048.18130.python-list@python.org>,
 Cameron Simpson <cs@zip.com.au> wrote:

> 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?

So, what are we talking about here?  my_lightbulb == your_lightbulb, or 
my_lightbulb === your_lightbulb, or my_lightbulb is your_lightbulb?  Or 
just sha1(my_lightbulb) == sha1(your_lightbulb)?

[toc] | [prev] | [next] | [standalone]

#74342

On Fri, Jul 11, 2014 at 11:17 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.11744.1405038048.18130.python-list@python.org>,
>  Cameron Simpson <cs@zip.com.au> wrote:
>
>> 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?
>
> So, what are we talking about here?  my_lightbulb == your_lightbulb, or
> my_lightbulb === your_lightbulb, or my_lightbulb is your_lightbulb?  Or
> just sha1(my_lightbulb) == sha1(your_lightbulb)?

Probably type(my_lightbulb).__name__ == type(your_lightbulb).__name__,
knowing the reliability of support people...

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
nature? Does C-level code have to check this flag before comparing
nans, or is this applicable only to the Python float objects and only
when compared in Python? Is isnan() still usable? (Consider that x!=x
== math.isnan(x) normally.)

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web