On 03/05/2015 07:26 PM, Ben Finney wrote: > Ethan Furman <et...@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.
signature.asc
Description: OpenPGP digital signature
-- https://mail.python.org/mailman/listinfo/python-list
