One Answer, Not Three

A sequence of separate if statements asks every question. An if-elif chain asks questions only until one of them is answered yes, and then stops.

Both shapes are useful, and the bug is reaching for the wrong one. When the branches are alternatives, only one of them should ever run, and separate ifs cannot promise that.

Two things changed there, and both were needed. The second test became an elif, so the chain stops at its first success. The tests were also reordered, so the most demanding one is asked first. A chain in the wrong order is still wrong: with the low test written first, 84 would come out labelled green and the amber test would never be reached at all.

Python lets one value be compared against two bounds in a single expression. Write the low bound, then the value, then the high bound, with a comparison operator between each pair.

That means exactly what 18 <= t and t <= 32 means, and it reads the way the same range would be written in mathematics. The two operators need not match in strictness: 18 <= t < 32 keeps the low bound and excludes the high one. They must, though, point the same way. Python accepts 18 <= t >= 32 without complaint, but that is no longer a band. It asks for a value that is at least 18 and also at least 32, which is a different question with a different answer.

So far not has been applied to a single comparison. It can also be applied to a compound condition, and there it does something less obvious than flipping each side.

Once conditions are compounded it becomes possible to write one that is true for nothing at all, or one that is true for everything. Neither is reported as an error. The program runs, and a block quietly never executes.