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? 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 -- https://mail.python.org/mailman/listinfo/python-list
