Is nan in (nan,) correct?

[Ethan Furman]

On 03/05/2015 07:26 PM, Ben Finney wrote:
> 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?

No, it's not a /may/, it's a /does/, and that it can be optimized is a bonus.

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

The NaN-type objects cannot deal with it directly, as that behavior is in the container.

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

Well, we can depend on it for native Python types -- but if you write your own container, along with your own
__contains__, then you might unwittingly do  `for item in self.container: if item == target:  return True` and then NaN
(or NullType, or what-have-you) would not work "correctly" [1] for your container.

--
~Ethan~

[1] Otherwise known as: how Python does it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20150305/705357ee/attachment.sig>