Live data from Hacker News

New Ways to Be Told That Your Python Code Is Bad

nickdrozd.github.io

71–80 of 262 posts

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

#71

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.

Also worth remembering that a perl statement can be converted into an expression with a do block, so you can write

    my $x = do {
      if (foo()) {
        4
      } else {
        5
      }
    };
(and yes, I know, that example would look fine as a ternary - but this is meant to illustrate the syntax possibility, not where I'd specifically use it - and once the logic within one of the two conditional branches gets more complicated, switching to do+if+else can make for clearer code)

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

#72
> You know what else doesn’t have unbounded loops? Excel.

Right, one of the many reasons why nobody (with half a brain) hosts a web server in Excel.

I wonder how much "boring web app" experience the author had. If I'm debugging on 11 pm why the webserver is timing out talking to microservice A, but only if it first opened connection to service B, and someone strolls along saying "Hey, your code is bad because it's using unbounded computation," then god help us, because I might lose it. (Well, shrug, the worst that can happen is that I may rage-quit on the spot. I'm not a very imposing guy.)

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

#73
While I appreciate the idea of bounded loops, it's a mistake to think that a `for` loop is necessarily bounded.

It's pretty easy to write a generator that produces an infinite sequence. That generator, of course, would need a `while` loop, but that loop can be in an external dependency which the linter is not checking.

You also can read way more than you expected if you use a `for` loop to read from a socket, or a file, to say nothing about reading from /dev/random.

Not that it's a bad advice, but it's not a rule, it's more like a... guideline. Discretion is still needed.

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

#74
post #70

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

Well his linter flags every occurrence, apparently. Because "that’s the fact of the matter, and you need to come to grips with it."

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

#75
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 the key point is that the linter doesn't ban anything. nobody is proposing removing while statements from the language. if you have a valid case for disobeying the linter, then you can disable the linter for that line: https://pylint.pycqa.org/en/latest/user_guide/message-contro... (if a project unconditionally bans PRs that don't pass the linter, that's a different issue, and not really the linter's fault)

I could certainly see a linter that says "are you sure?" before you initially add a while loop to make you ask yourself if that's really the best option being quite neat.

The trick would be making it sufficiently useful and minimally annoying that people don't get angry and turn it off.

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

#76
post #45

Earlier quoted context omitted.

Exactly. I prefer this a lot more to at least avoid using else: x = 5 if condition(): x = 4

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.

Yeah, Python's willingness to break up conceptual concepts into separate parts of an expression such that you might need to backtrack while reading has always seemed an odd choice to me, exemplified by list comprehensions, especially when nested.

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

#77
post #75

Earlier quoted context omitted.

i think the key point is that the linter doesn't ban anything. nobody is proposing removing while statements from the language. if you have a valid case for disobeying the linter, then you can disable the linter for that line: https://pylint.pycqa.org/en/latest/user_guide/message-contro... (if a project unconditionally bans PRs that don't pass the linter, that's a different issue, and not really the linter's fault)

I could certainly see a linter that says "are you sure?" before you initially add a while loop to make you ask yourself if that's really the best option being quite neat. The trick would be making it sufficiently useful and minimally annoying that people don't get angry and turn it off.

it's not really the linter's job to say "are you sure". the linter just applies the rules and generates messages, it's up to you to do with those messages what you will

when using the python integration in vscode (which runs pylint), clicking on a linter error gives me a context menu where one of the options is essentially "are you sure?" and will automatically adds the appropriate comment to disable the linter for that line.

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

#78
post #27

>most code is not complex enough to warrant while loops, scale = 5 while (scale > 0.1): do_stuff(scale) scale = scale/2 Sure, you could use exponentials with range(), but is that really clearer?

Ironically (to me at least, because it's a construct I use -far- more rarely than while), this actually seems like a case where a C-style for loop might actually be nicer:

    for (my $scale = 5; $scale > 0.1; $scale /= 2) {
      do_stuff($scale);
    }

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

#79
post #70

Earlier quoted context omitted.

I guess `quitRequested` falls in: > anything that runs for as long as the user says it should run; Per the article...

Well his linter flags every occurrence, apparently. Because "that’s the fact of the matter, and you need to come to grips with it."

If you enable it. And if you really care about avoiding while-loops, you can still silence it for the ones you really want to have (e.e. main loops like your example, as also mentioned in the article).

Probably not for me though.

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

#80
post #71

Earlier quoted context omitted.

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.

Also worth remembering that a perl statement can be converted into an expression with a do block, so you can write my $x = do { if (foo()) { 4 } else { 5 } }; (and yes, I know, that example would look fine as a ternary - but this is meant to illustrate the syntax possibility, not where I'd specifically use it - and once the logic within one of the two conditional branches gets more complicated, switching to do+if+els…

I had a good chuckle as while reading this comment I was thinking "oh, I saw code like that just last week while reading SQL::Abstract's source", and then I saw the username. :)
Post reply on HN