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

61–70 of 262 posts

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

#61

Post by chrismorgan »

hermitdev wrote: post #59
tempest_ wrote: post #37

Earlier quoted context omitted.

why "while 1:" and not "while true:"?

Because "while 1:" is valid Python, but "while true:" is not ;) (gotta capitalize "True"). In addition to the GP's self deprecating sibling comment, I started using Python around 2.2, before there were even "True" and "False". So, seeing a 'while 1' loop is perfectly natural to me. But, I'm also perfectly comfortable with Python's "truthiness" in more places than most people are. As a bonus: consider "while 'false' :…

> consider "while 'false' :" as a perfectly valid start to an unbounded loop

That sort of thing is ubiquitous in dynamically-typed languages. Even HTML: the state of boolean attributes is determined by the attribute being set, regardless of its value, so will give you a nice disabled text box. Mind you, some attributes that you might think would be boolean actually aren’t, for varying reasons good and bad, e.g. autocomplete=on|off, aria-hidden=true|false.

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

#62

Post by priansh »

frosted-flakes wrote: post #60
priansh wrote: post #50

While I agree with the ternary linting, the while loop piece makes absolutely no sense. There are absolutely many, many use cases of while loops; in fact, many dynamic programming algorithms rely on them. Could you write them as a for loop? Possibly, but why? Is the new 2021 programming fad hating on while loops? Who do I contact to exchange my "js bad" t-shirts for "while bad" laptop stickers? The logic behind disap…

Did you miss the fact that these rules are disabled by default?

It should never have been introduced or approved in the first place.

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

#63

Post by markrages »

hermitdev wrote: post #59
tempest_ wrote: post #37

Earlier quoted context omitted.

why "while 1:" and not "while true:"?

Because "while 1:" is valid Python, but "while true:" is not ;) (gotta capitalize "True"). In addition to the GP's self deprecating sibling comment, I started using Python around 2.2, before there were even "True" and "False". So, seeing a 'while 1' loop is perfectly natural to me. But, I'm also perfectly comfortable with Python's "truthiness" in more places than most people are. As a bonus: consider "while 'false' :…

I learned Python around that time, when the docs said that `open()` is deprecated and to use `file()` as a constructor instead. Still unlearning that habit.

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

#64

Post by H8crilA »

tbenst wrote: post #39
H8crilA wrote: post #30

The author mentioned this at the end, but banning while loops (and any other way for running a loop with a priori unknown number of iterations) actually decreases the expressiveness of a language - it becomes no longer Turing complete. A classic example is the Ackerman function - it cannot be computed in a primitive recursive language. (The author is on point when they say almost all code used in practice is primitiv…

I think “while loops” are orthogonal to primitive recursive functions.. for example, here’s how to compute the Ackerman function using only recursion in several languages; https://stackoverflow.com/questions/16115815/ackermann-very-...

It doesn't have to be a while loop. Recursion is another way to implement a loop with a priori unknown number of iterations. You can also use goto.

And no, they aren't othogonal. A simple language with only integer variables, basic arithmetic, if() and for(i in range(x,y)) is actually not Turing complete.

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

#65

Post by Chris_Newton »

markrages wrote: post #47
chriswarbo wrote: post #38

Earlier quoted context omitted.

Even clearer: scale = 5 # The alternative would be exponentials with range(), # but it's clearer to use 'while' # pylint: disable=[while-used] while (scale > 0.1): do_stuff(scale) scale = scale/2 Less sarcastically, how about: scales = itertools.takewhile( lambda n: n > 0.1, functools.reduce(lambda x, y: x / y, itertools.repeat(2), 5) ) map(do_stuff, scales) This would be even easier with an 'iterate(x, f)' function…

Poe's law demonstrated.

Indeed, though in a language designed for this style of programming, the idea behind that final example in the GP comment works fine. A Haskell version might look something like this:

    iterate (/2) 5.0
      & takeWhile (>0.1)
      & map do_stuff
The `iterate` generates the infinite sequence, the `takeWhile` specifies how much of it to use, and then we do stuff with each element.

This is arguably a little nicer than the while loop since it exposes the real sequence of values you’re working with more explicitly, but at the very least it is comparably simple in its appearance. The Python version in the GP comment looks bad mostly because of the clumsy lambda syntax.

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

#67

Post by anigbrowl »

SavantIdiot wrote: post #40
anigbrowl wrote: post #23

Earlier quoted context omitted.

Yeah I don't like them as implemented, because most of my 'if' statements are in response to unforeseen things, so my mental expansion of it is 'Now, stop and check if...' I wouldn't mind it so much if I could write it as: x = 4 unless shenanigans(); then x = 5 Yes, that is a semicolon. Fight me.

That's PERL right there. Makes way more sense to my brain to read: print unless $x ~ /end$/; then print if $x !~ /end$/; I used to get flack for using not just if expressions as ternaries, but also for using unless. Then I started teaching PERL at my company and drilled it into all the fresh new minds.

I gotta be honest and say I like Python because it only has a limited amount of punctuation.

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

#68

Post by QuadrupleA »

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'

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

#69

Post by QuadrupleA »

So is the author suggesting that a while loop like this:

    while not quitRequested:
        processNextEvent()
Should be rewritten to this?

    for i in range(999999):
        if quitRequested:
            break
        processNextEvent()
Because that's supposedly guaranteed to halt? If so he's either joking or crazy. And his program will crash for his poor users after 999999 events.

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

#70

Post by tutuca »

QuadrupleA wrote: post #69

So is the author suggesting that a while loop like this: while not quitRequested: processNextEvent() Should be rewritten to this? for i in range(999999): if quitRequested: break processNextEvent() Because that's supposedly guaranteed to halt? If so he's either joking or crazy. And his program will crash for his poor users after 999999 events.

I guess `quitRequested` falls in:

> anything that runs for as long as the user says it should run;

Per the article...

Post reply on HN