> Python programmers in general have an irrational aversion to if-expressions, a.k.a. the “ternary” operator. Because the Python ternary operator is fucking backwards! Why on earth would you put the condition in the middle !? x = 4 if condition() else 5 vs.: condition() ? 4 : 5 vs. the author's own lisp example: (setq x (if (condition) 4 5)) I love ternary operators, and Lisp/ML-style if else blocks that return thing…
I love the Python version, it reads like English. Use umbrella if raining, else wear shades.
New Ways to Be Told That Your Python Code Is Bad
171–180 of 262 posts
Re: New Ways to Be Told That Your Python Code Is Bad
#172> Python programmers in general have an irrational aversion to if-expressions, a.k.a. the “ternary” operator. Because the Python ternary operator is fucking backwards! Why on earth would you put the condition in the middle !? x = 4 if condition() else 5 vs.: condition() ? 4 : 5 vs. the author's own lisp example: (setq x (if (condition) 4 5)) I love ternary operators, and Lisp/ML-style if else blocks that return thing…
Re: New Ways to Be Told That Your Python Code Is Bad
#173Tools that enforce "expert level" coding standards do make code more concise, but also less comprehendible for the less experienced developers. I never saw the harm in four lines of code instead of one, especially when it's much more readable.
Python is a sane language that you can master in a reasonable amount of time. If you think expecting people to achieve Python mastery is unreasonable, wait until I tell you about language called C++.
I would never demand this for someone writing a Python app or module that out team would use as a normal import, just the stuff we actively manage.
Re: New Ways to Be Told That Your Python Code Is Bad
#174Ah, leave people alone. I stopped using ternary expressions because someone told me not to. I could start using them again, whatever. I use while loops when the burden of describing the loop as an iteration is too high (too much of a stretch), or when I'm writing something that really isn't a composition of forEach/map/filter/reduce (gasp). For me, it's whatever I need to do to get through code review without arguing…
I'm most likely less experiment than some people here but after 10+ years of writing code, I came to the conclusion that the best code is the most readable code.
If all developers could write code that is easily readable for them (even after a few months break in the project), the software engineering world would be a lot better :)
Of course it makes sense to avoid anti-patterns and bottlenecks, but no much more really.
Re: New Ways to Be Told That Your Python Code Is Bad
#175Earlier quoted context omitted.
My favorite way to write that is with expression oriented langauges. Example in OCaml: x = if condition() then 5 else 4 I dislike how the regular order of if is changed when used as an expression. I don't know how you could retrofit that into existing Python tough. Probably a consequence of defining blocks with whitespaces.
It is simply a design choice, the common value is given first. Comprehensions in Py are the same.
Infix "if" conditions just scramble up the order of evaluation from the order of program source code.
Re: New Ways to Be Told That Your Python Code Is Bad
#176> Python programmers in general have an irrational aversion to if-expressions, a.k.a. the “ternary” operator. Because the Python ternary operator is fucking backwards! Why on earth would you put the condition in the middle !? x = 4 if condition() else 5 vs.: condition() ? 4 : 5 vs. the author's own lisp example: (setq x (if (condition) 4 5)) I love ternary operators, and Lisp/ML-style if else blocks that return thing…
x = 5
x = 4 if condition()Re: New Ways to Be Told That Your Python Code Is Bad
#177Earlier quoted context omitted.
What's so monstrous about it? It's practically English: cssClass = 'selected' if isCurrentTab else 'deselected'
You have a weird perception of English. "If the tab is selected, the CSS class is 'selected', else it's deselected. Or in pseudocode if isCurrentTab cssClass = 'selected' else cssClass = 'deselected' Even ternaries read weird. "css class is current tab HUH?? selected COLON! deselected"
Re: New Ways to Be Told That Your Python Code Is Bad
#178> Python programmers in general have an irrational aversion to if-expressions, a.k.a. the “ternary” operator. Because the Python ternary operator is fucking backwards! Why on earth would you put the condition in the middle !? x = 4 if condition() else 5 vs.: condition() ? 4 : 5 vs. the author's own lisp example: (setq x (if (condition) 4 5)) I love ternary operators, and Lisp/ML-style if else blocks that return thing…
I’ll give a shot at answering your rant with another one: I’ve never figured out those question marks. And in your example, what the hell even happens if condition is true or false? At least the lisp version has a function call that includes the word set, so you can kinda guess that the x variable is set. The if-expression reads very close to English, so you don’t need to look it up in the manual to read it. I wouldn…
It should be:
x = condition() ? 4 : 5Re: New Ways to Be Told That Your Python Code Is Bad
#179Linters are good because they stop people arguing. Some early employee in the team defines some set of rules, and that's just the way things are from then onwards. Less time bickering means more time spent doing actual productive stuff.
(Both of these statements can be true.)
Re: New Ways to Be Told That Your Python Code Is Bad
#180Earlier quoted context omitted.
For Turing's sake, if you insist on chaining ternary operators, then you should always use parens instead of showboating that you cleverly-by-half memorized a particular language's obscure precedence and associativity rules. PHP in all its glory and splendor actually originally used left-to-right instead of right-to-left associativity for the ternary ?: operator, so that expression you wrote works differently in PHP…
Still beats APL
https://en.wikipedia.org/wiki/APL_(programming_language)#Des...
>All primitives are defined to have the same precedence, and always associate to the right. Thus, APL is read or best understood from right-to-left.
But consistency across all languages is too much to ask for, except when one language is purposefully imitating another language's syntax but subtly changing it, like PHP did to C. Or the way Perl and PHP imitated C's syntax for references with &, implying that they were somehow alike and could be used in similar ways, even though they're totally different foot guns.
At least APL and FORTH and LISP pick a lane (albeit different sides of the road), and stay in it.