[Python-ideas] Warning on conditionals

[Andrew Barnert]

On Dec 17, 2013, at 8:15, spir <denis.spir at gmail.com> wrote:

> 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'.

No it isn't. The second operand is the string "Kids Earrings".  Which would be harder to debug, not easier.

> 
> 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.) [**]

Operator precedence is surprising once, but makes your life easier once you learn it. Prefix notation is unreadable once, and remains unreadable even after you learn it. It's as high a barrier as postfix (RPN) notation, but without the advantages. (Plenty of engineers use their trusty HP 48 happily. But no one uses prefix notation except programmers in languages like Java and Lisp dialects without infix, and all of them complain about it.) I assume no one is going to suggest turning Python into Forth, so why suggest turning it into a form that has all the disadvantages of both with the advantages of neither?

Anyway, it's easy to write a linter that enforces simple rules like not relying on precedence (forcing explicit parens), and then people (and teams, and teachers) who want to follow those rules can do so.

> 
> 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/
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/