{"id":514,"date":"2016-04-18T09:00:47","date_gmt":"2016-04-18T17:00:47","guid":{"rendered":"http:\/\/blogs.msdn.microsoft.com\/pythonengineering\/?p=514"},"modified":"2019-02-17T15:27:09","modified_gmt":"2019-02-17T22:27:09","slug":"idiomatic-python-boolean-expressions","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/python\/idiomatic-python-boolean-expressions\/","title":{"rendered":"Idiomatic Python: boolean expressions"},"content":{"rendered":"

You might think that boolean expressions — most frequently used as conditional guards which are the the bit of code that tests whether an if<\/code> or while<\/code> 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.<\/p>\n

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<\/a> in Python 3 is:<\/p>\n

False<\/code>, None<\/code>, 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 __bool__()<\/code> method.<\/p><\/blockquote>\n

A bit of Python history: During the discussion of adding the boolean type in Python 2.3<\/a>, 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<\/strong> False<\/code>” which some viewed as a loss of simplicity. On the other side people argued that False<\/code> helped make code clearer. In the end the side arguing that the concept of False<\/code> was larger and thus the side for clearer code won. You might also have noticed that booleans are not that<\/em> old in Python, which is why booleans can (mostly) be treated as integers due to backwards-compatibility with code that simply used 1<\/code> and 0<\/code> to represent True<\/code> and False<\/code>, respectively.<\/p>\n

The first piece of advice is to not overdo the use of is<\/code> comparisons. The is<\/code> is for identity comparisons<\/a> which means it evaluates to True<\/code> 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:<\/p>\n

40 + 2 is 42  # True in CPython, not necessarily in other VMs.<\/pre>\n
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<\/code> with numbers works with any number, which isn’t true if you try something like:<\/p>\n
2**32 is 2**32 # False.<\/pre>\n
which evaluates to False<\/code>. In other words, only use is<\/code> if you really, really<\/strong> want to test for identity and not value.<\/p>\n
Another place where we have seen is<\/code> used in a non-idiomatic fashion is directly testing for True<\/code> or False<\/code>, e.g.:<\/p>\n
something() is False  # Too restrictive.<\/pre>\n
not something()  # Just right.<\/pre>\n
And this extends to other types as well, so don’t do spam == []<\/code> if you care if something is empty, simply do not spam<\/code> in case the API that gave you the value for spam<\/code> suddenly starts returning tuples instead of lists.<\/p>\n
About the only time you might legitimately find the need to use is<\/code> in day-to-day code is with None<\/code>. Sometimes you might come across an API where None<\/code> has special meaning, in which case you should use is None<\/code> to check for that specific value. For example, modules in Python have a __package__<\/code> attribute<\/a> 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__<\/code> 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__<\/code> should be set to. In that instance, None<\/code> is used to represent “I don’t know”. This allows the code that calculates what package a module belongs to<\/a> to use:<\/p>\n
package is None  # OK when you need an \"I don't know\" value.<\/pre>\n
to detect if the package name isn’t known (not package<\/code> would incorrectly think that ''<\/code> represented that as well). Do make sure to not overuse this kind of use of None<\/code>, though, as a false value tends to meet the need of representing “I don’t know”.<\/p>\n
Another bit of advice is to think twice before defining __bool__()<\/code> 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\u00a0stop and think about whether it truly makes sense to define the method. While it may be tempting to use __bool__()<\/code> 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<\/code>\u00a0which 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__()<\/code> can be surprising, see the Python issue<\/a> where there was a multi-year discussion over how defining datetime.time()<\/code> 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__()<\/code> was removed in Python 3.5<\/a>).<\/p>\n
If you find yourself needing to provide a specific default value when faced with a possible false value, using or<\/code> can be helpful. Both and<\/code> and or<\/code> don’t return a specific boolean value but the first value that forces a known true value. In the case of or<\/code> 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:<\/p>\n
# Use the value from something() if it is true, else default to None.\nspam = something() or None<\/pre>\n
then spam<\/code> would gain the value from something()<\/code> if it was true, else it would be set to None<\/code>. And because both and<\/code> and or<\/code> short-circuit, you can combine this with some object instantiation and know that it won’t occur unless necessary;<\/p>\n
# Only execute AnotherThing() if something() returns a false value.\nspam = something() or AnotherThing()<\/pre>\n
won’t actually execute AnotherThing()<\/code> unless something()<\/code> returns a false value.<\/p>\n
And finally, make sure to use any()<\/code><\/a> and all()<\/code><\/a> when possible. These built-in functions are very convenient when they are needed and when combined with generator expressions they are rather powerful.<\/p>\n","protected":false},"excerpt":{"rendered":"
You might think that boolean expressions — most frequently used as conditional guards which are the the bit of code that tests whether an if or 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 […]<\/p>\n","protected":false},"author":386,"featured_media":10119,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[9,13],"class_list":["post-514","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-python","tag-code-style","tag-idioms"],"acf":[],"blog_post_summary":"
You might think that boolean expressions — most frequently used as conditional guards which are the the bit of code that tests whether an if or 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 […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/python\/wp-json\/wp\/v2\/posts\/514","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/python\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/python\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/python\/wp-json\/wp\/v2\/users\/386"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/python\/wp-json\/wp\/v2\/comments?post=514"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/python\/wp-json\/wp\/v2\/posts\/514\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/python\/wp-json\/wp\/v2\/media\/10119"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/python\/wp-json\/wp\/v2\/media?parent=514"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/python\/wp-json\/wp\/v2\/categories?post=514"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/python\/wp-json\/wp\/v2\/tags?post=514"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
This is technically not wrong like with the previous example because False<\/code> is a singleton — just like None<\/code> and True<\/code> — which means there is only one instance of False<\/code> to actually compare against. Where this goes astray is it is unnecessarily restrictive. Thanks to Python being a huge proponent of duck typing<\/a>, tying down any API specifically to only True<\/code> or False<\/code> 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<\/code>, the code should have simply checked for false value:<\/p>\n