Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Ways to Be Told That Your Python Code Is Bad

nickdrozd.github.io

Post reply on HN
Print view View original

181–190 of 262 posts

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

#181

Post by dethos »

Is this a joke, right?

    Do you really need unbounded computation for your boring web app?
Because everyone using python is working on web application. Also because all web applications have the same type of business logic.

I do like linters, the best ones help avoiding mistakes and ensure some consistency in the codebase, but this article goes a bit too far.

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

#182

Post by dragonwriter »

junon wrote: post #155
dragonwriter wrote: post #126

Earlier quoted context omitted.

Honestly, the Python version is far more readable to me than the C, and that's even with close to a decade with C before encountering Python or any other language using that style. Though Ruby’s unless modifier is often slightly better for readability.

In C, I always put the ternary clauses on their own lines prefixed with the operator. This always makes things readable. int result = condition ? value * 12 : something_else(); and in the case where the condition is sufficiently complex: int result = ( some_condition() && another_condition() && yet_another_condition() ) ? value * 12 : something_else(); For me, at least, this is entirely readable. The unfortunate bit…

> The unfortunate bit is that there is no formatter in existence (yet) that can handle this for C, or really any other language with similar syntax.

Prettier does it fine for JS, which uses C-style ternary syntax.

> Python's "Black" formatter actually does the best job here, yet the python ternary syntax is still very verbose and strange IMO.

To me, its quite natural when used sensibly, since if you drop everything after the if it is the normal-case value. Though I would slightly prefer if the ternary form was:

   unless  then
instead of:

   if  else

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

#183

Post by chrismorgan »

DonHopkins wrote: post #162
pdpi wrote: post #143

Earlier quoted context omitted.

There are some specific shapes of chained ?: that are fairly legible. Eg c = condA ? valA : condB ? valB : defaultVal;

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…

As PHP’s RFC says, right-associative ternary is useful and intuitive. I don’t need no parentheses, the meaning is clear and obvious and doesn’t go wrong in any environment that I or those I work with use, and doesn’t even go wrong in PHP any more (warning in 7.4, syntax error in 8). I’m not going to compromise the beauty and editability of my code by inserting superfluous parentheses—they’d make me have to think more about the meaning of the ternary chain, not less.

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

#184

Post by dragonwriter »

dragonwriter wrote: post #133
joatmon-snoo wrote: post #124

Earlier quoted context omitted.

I've actually found that there are a number of situations where I really want: while True: ... if condition: break ... and kinda wish there was a nicer syntax for this.

A Ruby-like “until” or Pascal “repeat...until” (C’s do...while is equivalent but less clear choice of keywords, IMO.) The Pascal form wouldn't really fit Python's indentation-without-closing-marker block syntax preference, but the Ruby version would. If it existed, I’d be tempted to suggest a linter rule that prohibits break inside an until (it should only be used when the main exit condition is the only exit conditi…

Too late to correct, but I can tell I haven't been using Ruby much for a while; Ruby until is just negated while, like C it uses while (or until!) at the end for Pascal-style repeat...until logic.

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

#185

Post by maleldil »

dimitrios1 wrote: post #24
Spivak wrote: post #21

Earlier quoted context omitted.

I mean sure, that’s true of every programming language. The reason to follow community standards is to make the lives of other people reading your code easier. Consistency is far more important than any individual’s optimal style.

God bless gofmt and tools like prettier.

Python has Black, which uses the same premise as gofmt.

Guido doesn't like it, though, but the community seems to.

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

#186

Post by rcthompson »

ohazi wrote: 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 think the Python ternary is best read as "DEFAULT_VALUE if COMMON_CASE else FALLBACK", and is best used in situations where this is what is meant semantically. If you're dealing with two equally plausible code paths, the standard if/else branching structure makes that more clear.

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

#188

Post by hatmatrix »

ohazi wrote: 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 this Python syntax:

    x = condition() and 4 or 5

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

#189

Post by Uberphallus »

ohazi wrote: 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 Python but my personal hate goes for this when used in list comprehensions.

    a = [1,2,3]
    # list comprehension with if
    [ x for x in a if x > 1]
    [2, 3]
    # list comprehension with if/else
    [ x if x > 1 else x*2 for x in a]
    [2, 2, 3]
When it's just "if" it goes after the "for", when it's "if/else" it goes, all of it, before. I still don't understand why it's this way, it doesn't even make sense even reading it in natural language. I much prefer the mathematical-like syntax present in Scala for this.

Edit: Thanks for the responses, they are are insightful, never thought of this that way.

Still in my head the lack of "else" clause implies filtering no matter where, while its presence implies transformation no matter where. The first element of the list is always transformed (though in this example it's identity).

I think it's a case of Python trying to do too much with too little. Personally for anything relatively complicated I still prefer to use filter() and map() as list comprehensions can get unwieldly quick.

Post reply on HN