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

141–150 of 262 posts

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

#141

Post by fantod »

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…

> Why on earth would you put the condition in the middle!?

For readability.

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

#142

Post by vsnf »

matusp wrote: post #107

People raging over the ternary operation in Python should learn to use: x = {True: 5, False: 4}[condition()] , or if you don't want to evaluate the values: x = {True: lambda: 5, False: lambda: 4}[condition()]()

This is perhaps one of the most obscure ways to do ternaries I could have thought of, and while it really is quite clever, I think I'd be pretty annoyed if I encountered it in the wild.

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

#143

Post by pdpi »

Cthulhu_ wrote: post #136
chakkepolja wrote: post #125

Earlier quoted context omitted.

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.

There are some specific shapes of chained ?: that are fairly legible. Eg

    c = condA ? valA :
        condB ? valB :
        defaultVal;

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

#144

Post by MathMonkeyMan »

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

Don't add linter checks for these things, it's condescending.

At the very least, have the "greater good" on your side, e.g. "it confuses some people!" or "it is often a bug!" or "it can become a maintenance nightmare!" or whatever. If your reason is "I like it better this way," well then yeah, the reaction I would anticipate is "who asked you?"

The reason this bothers me isn't that I strongly disagree, but that I'm in the habit of doing whatever my linter tells me, and adding stuff like this cheapens the thing and makes it harder to sell to "I'm an expert, get off my lawn" people.

Why am I even writing this, I'm knee deep in C++ these days.

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

#146

Post by mst »

kbenson wrote: post #80
mst wrote: post #71

Earlier quoted context omitted.

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

Guilty as charged :D

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

#148

Post by MathMonkeyMan »

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…

Because that's what Guido liked, that's the answer.

I don't like it much, but it's neat that the "happy" path value is a prefix of the assignment statement, i.e. in

    x = 4 if thing() else -1
there is a prefix

    x = 4
which, if the predicate is "expected," is like saying

    x = value (... unless blah blah)
which, I could see some people liking (maybe Dutch people).

Let's just write everything in Scheme for God's sake JOIN US.

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

#149

Post by mst »

notatoad wrote: post #77
mst wrote: post #75

Earlier quoted context omitted.

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

I was thinking along the lines of something similar except for running the linter as a pre-commit hook.

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

#150

Post by jbverschoor »

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 usually do some sort of maximum recursion check. For things where I’d expect for example max 10 levels, I’d check for 1000-10000, and then raise an exception.
Post reply on HN