Idiomatic Python: boolean expressions
You might think that boolean expressions — most frequently used as conditional guards which are the the bit of code that tests whether an
while statement should execute — are a fairly straight-forward concept and that there isn’t really anything subtle to them at all. And while the general concept is simple, there are some idiomatic practices to follow when writing them.
To start off, we should make sure everyone understands what makes something considered true or false (sometimes referred to as being “truthy” or not). The official definition of what is true or false in Python 3 is:
None, numeric zero of all types, and empty strings and containers (including strings, tuples, lists, dictionaries, sets and frozensets). All other values are interpreted as being true. User-defined objects can customize their truth value by providing a
A bit of Python history: During the discussion of adding the boolean type in Python 2.3, some people didn’t like that the definition of what was considered false went from “anything that represents emptiness”, to “anything that represents emptiness and
False” which some viewed as a loss of simplicity. On the other side people argued that
False helped make code clearer. In the end the side arguing that the concept of
False was larger and thus the side for clearer code won. You might also have noticed that booleans are not that old in Python, which is why booleans can (mostly) be treated as integers due to backwards-compatibility with code that simply used
0 to represent
The first piece of advice is to not overdo the use of
is comparisons. The
is is for identity comparisons which means it evaluates to
True only if both objects involved in the expression are literally the same object (this has nothing to do with value). Unfortunately people can easily end up conflating an identity comparison with a value comparison. For instance, some people accidentally discover that some implementations of Python cache certain values for performance, leading to expressions like:
40 + 2 is 42 # True in CPython, not necessarily in other VMs.
being true. But this caching of numbers isn’t part of the language definition of Python, making it just a quirky side-effect of an implementation detail. This is a problem then if you either change Python implementations or happen to think that using
is with numbers works with any number, which isn’t true if you try something like:
2**32 is 2**32 # False.
which evaluates to
False. In other words, only use
is if you really, really want to test for identity and not value.
Another place where we have seen
is used in a non-idiomatic fashion is directly testing for
something() is False # Too restrictive.
This is technically not wrong like with the previous example because
False is a singleton — just like
True — which means there is only one instance of
False to actually compare against. Where this goes astray is it is unnecessarily restrictive. Thanks to Python being a huge proponent of duck typing, tying down any API specifically to only
False is frowned upon as it locks an API to a specific type. If for some reason the API changed to return values of a different type but has the same boolean interpretation then this code would suddenly break. Instead of directly checking for
False, the code should have simply checked for false value:
not something() # Just right.
And this extends to other types as well, so don’t do
spam ==  if you care if something is empty, simply do
not spam in case the API that gave you the value for
spam suddenly starts returning tuples instead of lists.
About the only time you might legitimately find the need to use
is in day-to-day code is with
None. Sometimes you might come across an API where
None has special meaning, in which case you should use
is None to check for that specific value. For example, modules in Python have a
__package__ attribute which stores a string representing what package the module belongs to. The trick is that top-level modules — i.e., modules that are not contained in a package — have
__package__ set to the empty string which is false but is a valid value, but there is a need to have a value represent not knowing what
__package__ should be set to. In that instance,
None is used to represent “I don’t know”. This allows the code that calculates what package a module belongs to to use:
package is None # OK when you need an "I don't know" value.
to detect if the package name isn’t known (
not package would incorrectly think that
'' represented that as well). Do make sure to not overuse this kind of use of
None, though, as a false value tends to meet the need of representing “I don’t know”.
Another bit of advice is to think twice before defining
__bool__() on our own classes. While you should definitely define the method on classes representing containers (to help with that “empty if false” concept), in all cases you should stop and think about whether it truly makes sense to define the method. While it may be tempting to use
__bool__() to represent some sort of state of an object, the ramifications can be surprisingly far-reaching as it means suddenly people have to start explicitly checking for some special value like
None which represents whether an API returned an actual value or not instead of simply relying on all object defaulting to being true. As an example of how defining
__bool__() can be surprising, see the Python issue where there was a multi-year discussion over how defining
datetime.time() to be false at midnight but true for all other values was a mistake and how best to fix it (in the end the implementation of
__bool__() was removed in Python 3.5).
If you find yourself needing to provide a specific default value when faced with a possible false value, using
or can be helpful. Both
or don’t return a specific boolean value but the first value that forces a known true value. In the case of
or this means either the first value if it is true or else the last value no matter what. This means that if you had something like:
# Use the value from something() if it is true, else default to None. spam = something() or None
spam would gain the value from
something() if it was true, else it would be set to
None. And because both
or short-circuit, you can combine this with some object instantiation and know that it won’t occur unless necessary;
# Only execute AnotherThing() if something() returns a false value. spam = something() or AnotherThing()
won’t actually execute
something() returns a false value.