Is nan in (nan,) correct?

Ben Finney ben+python at benfinney.id.au
Thu Mar 5 22:26:15 EST 2015


Ethan Furman <ethan at stoneleaf.us> writes:

> On 03/05/2015 06:55 PM, Ben Finney wrote:
>
> >     class NullType(object):
> >         """ A type whose value never equals any other.
> > 
> >             This type's values will behave correctly when tested for
> >             membership in a collection::
> > 
> >                 >>> foo = NullType()
> >                 >>> bar = NullType()
> >                 >>> foo is foo
> >                 True
> >                 >>> foo is bar
> >                 False
> >                 >>> foo == foo
> >                 False
> >                 >>> foo == bar
> >                 False
> >                 >>> quux = [foo, "spam"]
> >                 >>> "spam" in quux
> >                 True
> >                 >>> foo in quux
> >                 True
>
> Did you mean False here?  Because True is current behavior.

Isn't the point at issue that the Python interpreter *may* optimise by
assuming ‘is implies equality’, so the ‘in’ operator can fail if that
assumption is false?

I thought the problem was that types with custom behaviour, as with the
‘NullType’ example, needed to deal specially with the ‘is implies
equality’ optimisation Steven explained.

If that's the correct behaviour, and we can *depend* on it being
correct, then I don't see what the problem is.

-- 
 \          “What I have to do is see, at any rate, that I do not lend |
  `\      myself to the wrong which I condemn.” —Henry Thoreau, _Civil |
_o__)                                                    Disobedience_ |
Ben Finney




More information about the Python-list mailing list