The modern day ternary operator is well-known to most Pythonistas:
<expr_if_true> if <condition> else <expr_if_false>
It's officially known as a conditional expression and was introduced back in Python 2.5 with PEP 308. Some like it, some don't, and while discussing it with a colleague of mine he mentioned that there "used to be something a whole lot worse" around the code bases written by developers favoring ternary operators. He couldn't remember what it looked like as these events are 15 years in the past, but a few days later he came back to me with a code snippet like this:
No ternary operator you say?
Developers are creative and opinionated. Sometimes this mix leads to monstrosities, such as when creative developers who really liked ternaries created this pattern:
You're reading that right. It's a list with two elements, the first of which
is returned if the condition is
False and the second if it's
True. Here is
condition = True message_modern = "success" if condition else "failure" print(message_modern) # success message_old = ["failure", "success"][condition] print(message_old) # success
This will make perfect sense to a C programmer:
interchangeable, as are
0. And that's precisely how this works,
the underlying function that implements the list index
performs some rudimentary checks and then just uses the provided index as an
offset to the base pointer of the list.
But the hack isn't quite the same
At first glance, it may seem like the old hack with the list is functionally equivalent to the modern ternary operator. It isn't quite, though, because it lacks one very important property: lazy evaluation of the branches. In short, the ternary operator only evaluates the branch that it returns. Here's an example:
condition = False result_modern = 1 / 0 if condition else 42 print(result_modern) # 42 result_old = [42, 1 / 0][condition] # raises ZeroDivisionError: division by zero print(result_old)
The ternary operator does not result in a crash on division by zero as it does not evaluate the expression in the true-branch, whereas the old hack crashes immediately as it first evaluates both expressions and then returns one of them. To fully emulate the modern behavior we'd need something like this:
condition = False result_old = [lambda: 42, lambda: 1 / 0][condition]() print(result_old) # 42
Here we get lazy evaluation by virtue of wrapping the two branches in lambdas, and then executing the lambda that's returned. I think we can all agree that's not a pretty sight.
Conditional expressions are a good thing
Regardless of your stance on using ternary operators (or conditional expressions, as they're called in Python), it's probably a good thing they exist. Otherwise creative and opinionated programmers get around to hacks to emulate the behavior that end up being completely unreadable to others.