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-workin.... Maybe the case in which the if statement is defeated should rate a warning.
f p wrote:
When a newbie writes if animal == "cat" or "dog": ... it is clear that he has the wrong idea about how this is evaluated, but in the general case if animal == cat or animal_barks: ... this is not an error. A check would be of very limited use. That said, there is an external tool that issues a warning: $ cat tmp.py import random a = random.choice("ab") if a == "b" or "c": print "yes" else: assert False, "unreachable" $ pychecker tmp.py Processing module tmp (tmp.py)... yes Warnings... tmp.py:3: Using a conditional statement with a constant value (c)
On Dec 17, 2013, at 7:14, MRAB <python@mrabarnett.plus.com> wrote:
We have multiple different linters and style checkers for a reason. Until one of them is so clearly perfect that there's no need for the others, I think it would be more useful to make it easier to integrate checkers into IDLE than to try to duplicate their functionality. Also, a pretty high percentage of newbies don't use IDLE, so this wouldn't solve the problem for most people.
But no one uses prefix notation except programmers in languages like Java and Lisp dialects without infix
And I must say, even in Java and Javascript, the libraries with APIs people love often are the ones who use heavy method-chaining, like Guava and JQuery and Underscore. Other than the fact that the method names are alphanumeric instead of symbolic, method chaining is basically infix notation too. On Tue, Dec 17, 2013 at 11:55 AM, Terry Reedy <tjreedy@udel.edu> wrote:
On 12/17/2013 02:07 PM, f p wrote:
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/
On Dec 17, 2013, at 8:15, spir <denis.spir@gmail.com> wrote:
No it isn't. The second operand is the string "Kids Earrings". Which would be harder to debug, not easier.
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.
f p wrote:
When a newbie writes if animal == "cat" or "dog": ... it is clear that he has the wrong idea about how this is evaluated, but in the general case if animal == cat or animal_barks: ... this is not an error. A check would be of very limited use. That said, there is an external tool that issues a warning: $ cat tmp.py import random a = random.choice("ab") if a == "b" or "c": print "yes" else: assert False, "unreachable" $ pychecker tmp.py Processing module tmp (tmp.py)... yes Warnings... tmp.py:3: Using a conditional statement with a constant value (c)
On Dec 17, 2013, at 7:14, MRAB <python@mrabarnett.plus.com> wrote:
We have multiple different linters and style checkers for a reason. Until one of them is so clearly perfect that there's no need for the others, I think it would be more useful to make it easier to integrate checkers into IDLE than to try to duplicate their functionality. Also, a pretty high percentage of newbies don't use IDLE, so this wouldn't solve the problem for most people.
But no one uses prefix notation except programmers in languages like Java and Lisp dialects without infix
And I must say, even in Java and Javascript, the libraries with APIs people love often are the ones who use heavy method-chaining, like Guava and JQuery and Underscore. Other than the fact that the method names are alphanumeric instead of symbolic, method chaining is basically infix notation too. On Tue, Dec 17, 2013 at 11:55 AM, Terry Reedy <tjreedy@udel.edu> wrote:
On 12/17/2013 02:07 PM, f p wrote:
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/
On Dec 17, 2013, at 8:15, spir <denis.spir@gmail.com> wrote:
No it isn't. The second operand is the string "Kids Earrings". Which would be harder to debug, not easier.
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.
participants (8)
-
Amber Yust -
Andrew Barnert -
f p -
Haoyi Li -
MRAB -
Peter Otten -
spir -
Terry Reedy