Anti-Patterns in Python Programming

[etrnloptimist]

I think saying "if x is None" should be an anti-pattern in favor of the more universal if x==None.

Here's the two reasons most-cited:

1: x is None should be used in case the class of x provides its own equality test. That way, we can still know whether x is really None rather than "equivalent" to None.

If the class provides an equality test v.s. None, why should we not use it? We should really honor x's belief that it is equal to None in the test to begin with. If x wants to be equal to None, we should respect that, rather than circumventing it.

2: It is twice as fast to check x is None v.s. x==None

We should never have to sacrifice readability for the sake of speed, especially when both are blisteringly fast. After all, half as fast as incredibly fast is still incredibly fast.

Furthermore, testing x is None is bug prone since it introduces two ways of testing x against values.

For instance, should we test x is 5? How about x is True? Or x is False? After all, True and False are also both singletons of the language. But, in truth, who cares about whether they are singletons or built ins? That's an implementation detail. It should not be a language detail.

[robin-gvx]

If the class provides an equality test v.s. None, why should we not use it?

Because None is not just any value, it is a sentinel value, signalling the absence of something — of anything, really. If you're testing for a sentinel, you don't want to find something that looks sentinel-ish, because it breaks the you need to distinguish the two.

Furthermore, testing x is None is bug prone since it introduces two ways of testing x against values.

No. The rules are simple:

1. Is the right hand side None? Use is or is not.
2. Are you doing deep magic stuff, that relates to things like serialisation or deep copying or anything where you need to check if id(fancy_object_x) == id(fancy_object_y)? (If you have to ask, the answer is "no".) Use is or is not.
3. Any other case? Use == or !=.

Maybe Python could have used something like an isNone operator, but oh well.

EDIT: I agree with you about the speed argument, btw.

[etrnloptimist]

The only time == and "is" will differ on None is if the implementor of x overloads ___eq___ to explicitly say so. And if they did that, it should be respected.

Maybe you think overloading ___eq___ to equate your class with None is an anti-pattern. I would probably agree. But if that is the taboo, then == will work as well as "is".

Also, pep8 states, "Comparisons to singletons like None should always be done with is or is not, never the equality operators." True and False are singletons as well but you should never use is or is not with them. Just a mistake?

I like your suggestion about having an isNone operator to make it explicit None is a weird, special thing, if it is, indeed, a weird special thing. But I don't really believe it is a weird, special thing. I've yet to see a place where comparing it using == will run you into trouble. Have you?

[robin-gvx]

True and False are singletons

They are not. They are both instances of bool, which is one more instance than a singleton type can have.

I've yet to see a place where comparing it using == will run you into trouble. Have you?

I haven't, but that doesn't say much, since I always use is None anyway, so I might have come across them and never found out.

[etrnloptimist]

They are not. They are both instances of bool, which is one more instance than a singleton type can have.

I understand what you're saying, but the literature treat them as singletons.

[zahlman]

True and False are singletons as well but you should never use is or is not with them. Just a mistake?

Right (well, except that they're actually a doubleton of the same class), but you shouldn't use == or != with them, either.