Live data from Hacker News

New Ways to Be Told That Your Python Code Is Bad

nickdrozd.github.io

171–180 of 262 posts

Re: New Ways to Be Told That Your Python Code Is Bad

#171
post #122

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

Is this how you would say it in English though? I think "If raining use umbrella else wear shades" is closer to regular English.

Re: New Ways to Be Told That Your Python Code Is Bad

#172
post #122

> 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…

If you don't like awkward ugly clunky syntax, you probably shouldn't program in Python. And, for that matter, if you like correctness checking, you also shouldn't program in Python...

Re: New Ways to Be Told That Your Python Code Is Bad

#173

Tools 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++.

Agreed, but I work with a lot of sysadmins who will never master Python. They'll use it, but never be at the level of a software developer. And that's OK because they have tons of other skills which are super valuable. I'd rather have our monitor scripts and glue code be more readable than complex.

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

#174

Ah, 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…

This, really.

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

#175
post #45

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

But when you write "condition ? first : second" or "(if condition first second)", the first common value is still given before the second uncommon value, so what's the advantage of putting the condition BETWEEN first and second, instead of BEFORE? After all, the condition has to be EVALUATED first before deciding which one to use.

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
post #122

> 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 prefer perl's style, which IIRC is also in ruby and coffeescript:

    x = 5
    x = 4 if condition()

Re: New Ways to Be Told That Your Python Code Is Bad

#177

Earlier 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"

“Set css class to ‘selected’ if it’s the current tab, or else ‘deselected’.”

Re: New Ways to Be Told That Your Python Code Is Bad

#178
post #122

> 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…

The C example doesn't match the others as the assignment is missing.

It should be:

  x = condition() ? 4 : 5

Re: New Ways to Be Told That Your Python Code Is Bad

#179

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

Linters are bad because they force your code into unnatural shapes, preventing you from exposing visual patterns and harming code comprehension, and also regularly harming diff sizes.

(Both of these statements can be true.)

Re: New Ways to Be Told That Your Python Code Is Bad

#180
post #170

Earlier 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

No, consistency within a language is good!

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.

Post reply on HN