[Python-ideas] Warning on conditionals
spir
denis.spir at gmail.com
Tue Dec 17 17:15:42 CET 2013
On 12/17/2013 02:07 PM, f p wrote:
> Hi, I'm new here,
>
> There are cases of bad use of int or str constants without comparison operators in the if statement as shown in this example:
>
> http://stackoverflow.com/questions/20633818/python-if-elif-always-not-working.
>
> Maybe the case in which the if statement is defeated should rate a warning.
Original code (from stackoverflow) is:
if taxon == "Bracelets":
catId = "178785"
elif taxon == "Kids Earrings" or "Earrings":
catId = "177591"
[...more elif's...]
The actual design issue, in my view, is reproducing in programming operator
priority from math syntax. If there were no such priority (at least, for logical
operators), then people would have to write:
elif (taxon == "Kids Earrings") or "Earrings":
catId = "177591"
...which makes semantic error obvious, or at least easy to understand, since in:
elif taxon == ("Kids Earrings" or "Earrings"):
catId = "177591"
the second operand is a logical value, compared to a 'taxon'.
Without parenthesis grouping, however, a "fuzzy logic" (lol!),
natural-language-like meaning is well possible, indeed it is the original
coder's intent.
Related, but distinct, it is well known that priority of logical and/or is quite
an effective source of bugs (also, the closer binding of not). And I remember a
study about expressions with operators [*] showing how common bugs about plain
arithmetic operator priority are (+-*/), as surprising as is. Evident
conclusion, i guess is that operator priority in programming is bad. (For
additional reasons, I guess the right choice in programming is prefix syntax
operations.) [**]
Denis
[*] The purpose of the study, IIRC, was about syntactic complexity of
operations, but it produced such data about error sources as a side-product.
[**] Actually, the same applies to math syntax, but there a revolution is even
less probable -- see how reluctant mathematicians are to abandon the funny idea
of PI beeing "the circle constant". http://tauday.com/
More information about the Python-ideas
mailing list