New Ways to Be Told That Your Python Code Is Bad
&gt; Anyway, this is just a style thing. It doesn’t affect program correctness or structure in a meaningful way.<p>The nice thing about ternaries is that they&#x27;re expressions, so they don&#x27;t &quot;infect&quot; our code like statements (e.g. &#x27;if&#x27;). For example:<p><pre><code>    if xCond:
      x = x1
    else:
      x = x2
    if yCond:
      y = y1
    else:
      y = y2
    if zCond:
      z = z1
    else:
      z = z2
    foo(x, y, z)
</code></pre>
This lint rule will tell us to do the following instead:<p><pre><code>    x = x1 if xCond else x2
    y = y1 if yCond else y2
    z = z1 if zCond else z2
    foo(x, y, z)
</code></pre>
Now that our branching is done with expressions rather than statements, we can actually in-line them, which seems much nicer (less chance to get them mixed up; no need to invent new names; no side-effects, e.g. accidentally overwriting an existing variable; etc.)<p><pre><code>    foo(
      x1 if xCond else x2,
      y1 if yCond else y2,
      z1 if zCond else z2,
    )
</code></pre>
If we really want the names, we could define them using the &#x27;walrus operator&#x27;:<p><pre><code>    foo(
      x := (x1 if xCond else x2),
      y := (y1 if yCond else y2),
      z := (z1 if zCond else z2),
    )

</code></pre>
Personally I would use separate &#x27;x = ...&#x27; statements rather than :=, since we want to explicitly perform effects (binding names).