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

131–140 of 262 posts

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

#131

Post by dragonwriter »

markrages wrote: post #35

Python doesn't have a do..while loop, so when you want to do a thing at least once, the simplest replacement is starting the loop with "while 1:" and ending the loop with "if ... break". I disapprove of any linter that flags this idiom.

> Python doesn't have a do..while loop

Python doesn't have an “[repeat...]until” loop, which C misspells as “do...while”, which fails to express what is going on.

> so when you want to do a thing at least once, the simplest replacement is starting the loop with "while 1:" and ending the loop with "if ... break".

“while True:” is more idiomatic Python (“while 1:” works since 1 is truthy, but using a literal 1 for “True” is a C-ism, Python has True as a literal for quite some time and idiomatic Python uses it.)

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

#132

Post by _ZeD_ »

I have problem with both new checkers:

regarding the `consider-ternary-expression`

    if condition():
       x = 4
    else:
       x = 5
allow me to put fck'n breakpoints - in this case the expression is dumb, but what if is some complex stuff?

    x = 4 if condition() else 5
is cute, but - remember, kids - not everything* should be an expression

regarding the `while-used`, while I personally prefer the legibility of the `for` loop, I find the following paragraph... at best wrong:

>>> A while loop introduces unbounded computation. Do you really need unbounded computation for your boring web app? I doubt it. In almost all cases, the loop can be bounded in advance, as in “do this N times” or “do this for every item in this list”. Those kinds of loops are guaranteed to terminate, and that’s a nice guarantee to have.

in python `for` loop are equally unbounded as `while` ones. Yes, most of the time you are looping over a (finite) list or a (finite) dict, but the concept underlying the `for` loop is the iterator, not the list. And iterators can easily be infinite.

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

#133

Post by dragonwriter »

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

> But here’s the reality: most code is not complex enough to warrant while loops, and most while loops are better written as for loops. Hard disagree. Obviously, if the loop is a fixed number of iterations or iteration over a collection (which is trivial to identify by human inspection but probably not for a linter), a for loop is better but it is not uncommon to be looping until a (possibly compound) condition becom…

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

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

#134

Post by dkersten »

dragonwriter wrote: post #123

> But here’s the reality: most code is not complex enough to warrant while loops, and most while loops are better written as for loops. Hard disagree. Obviously, if the loop is a fixed number of iterations or iteration over a collection (which is trivial to identify by human inspection but probably not for a linter), a for loop is better but it is not uncommon to be looping until a (possibly compound) condition becom…

In my personal experience, its quite rare outside of a few specific cases where I need unbounded loops. The specific cases where I do need them tend to be event loops -- a game loop, a consume the queue loop, a read and process input loop, etc, basically waiting on some external (to that code, not necessarily to the program) data, forever until the program is told to stop. Sometimes they're provided for me by some library or framework, sometimes I need to write them myself.

Almost every other case, in my own code at least, is a bounded loop. Usually processing a collection, but also often processing bounded ranges.

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

#135

Post by dkersten »

Zababa wrote: post #52

I really hope that the condescending tone of the article was because the author was tired or something, and that it's not the attitude they use when contributing to a linter. The authors comes out as arrogant and self-centered, the "reactions" are strawmans, the tone is aggressive. Sure that nice Beeping Busy Beaver uses only one loop, very cool. The "guessing game" program that almost everyone wrote when learning pr…

> forbids using bold text

Hah. Once-upon a time, I relied on bold text a lot for emphasis. Then I learned that its a crutch for bad writing, so I made an effort to use it very sparingly. I think my written material has improved substantially because of it. I think keeping bold text to a minimum is a good rule to follow when writing.

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

#136

Post by Cthulhu_ »

chakkepolja wrote: post #125
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…

In practice it's not that bad. One bad thing is you can't write long chains as you can do with C-style ternary operator.

That's not a bad thing, long ternary chains are illegible. You should never have more than one condition in a ternary.

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

#137

Post by Cthulhu_ »

jackdh wrote: post #118
chriswarbo wrote: post #16

> Anyway, this is just a style thing. It doesn’t affect program correctness or structure in a meaningful way. The nice thing about ternaries is that they're expressions, so they don't "infect" our code like statements (e.g. 'if'). For example: if xCond: x = x1 else: x = x2 if yCond: y = y1 else: y = y2 if zCond: z = z1 else: z = z2 foo(x, y, z) This lint rule will tell us to do the following instead: x = x1 if xCond…

I think I might be in the minority here that I prefer the fully laid out statements. Sure in small cases this small ternary use is great! However too many times I've seen people chain them for far too many characters just to be "on one line". We don't use one letter variable names anymore, so in the same reasoning why should we do the same to our code?

Yup; the booleans are difficult enough from a logic point of view, don't need to make it more complicated by using syntactic sugar.

I strongly disagree with the author's idea that shorter is better. Clarity trumps conciseness. I'll admit that not enough conciseness can impact clarity, but there's ways and means to clean that up that don't involve clever code.

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

#138

Post by Cthulhu_ »

QuadrupleA wrote: post #68
zootboy wrote: post #4

> less code is better than more code Not when it's at the cost of readability. The example "better" code fails my readability test horribly. I'd gladly take C's ternary operator over this monstrosity: > x = 4 if condition() else 5

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

#139

Post by karatinversion »

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 don't think it's backwards, it's just different than C and derivatives, and makes different things simple. I quite like the

  x = ( 1/y if y > 0 else
       -1/y if y
idiom.

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

#140

Post by ghgr »

_ZeD_ wrote: post #132

I have problem with both new checkers: regarding the `consider-ternary-expression` if condition(): x = 4 else: x = 5 allow me to put f ck'n breakpoints - in this case the expression is dumb, but what if is some complex stuff? x = 4 if condition() else 5 is cute, but - remember, kids - not everything* should be an expression regarding the `while-used`, while I personally prefer the legibility of the `for` loop, I find…

> in python `for` loop are equally unbounded as `while` ones. Yes, most of the time you are looping over a (finite) list or a (finite) dict, but the concept underlying the `for` loop is the iterator, not the list. And iterators can easily be infinite.

Not only iterators, but also plain lists. Example:

  a=[1]
  for i in a:
    a.append("the ride never ends")
    print(i)
Post reply on HN