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

211–220 of 262 posts

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

#211

Post by WesolyKubeczek »

Inspired by the boldness of this article, I decided to make my own linter which was going to be the most opinionated of them all.

Since my gut feeling is that 99% of the code is always shit that should not have been written at all, I have coded a linter that simply flags every line of your code and strongly advises you to delete it. And also change your trade if you can.

This linter was a very good invention. But then I got caught up in the spirit of being fair and “eating my own dog food”, and ran the ultimate linter on its own code.

It told me the code was pathetic shit and that I should delete it, and never write a line of code again because very likely it was going to be same shit, but worse.

I followed its advice.

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

#212

Post by Zababa »

29athrowaway wrote: post #208
Zababa wrote: post #93

Earlier quoted context omitted.

Linters tell you when your code doesn't respect certain rules. That's it. These rules may or may not lead to better programming, that depends on the rules themselves. I could build a linter that forbids all variable names longer than three characters. Would that make the code good? I doubt it. Sometimes the extra weight you notice on the scale is just muscle, and there's nothing to worry about.

That's a straw man argument.

That's not an argument but an example. You associated linters and scales saying that people hate them because they tell the truth. My argument is that the truth that these tools express is limited. A basic scale can only tell you if your weight went up, down or stayed the same. It's a useful information but it lacks context and can be misinterpreted if taken alone. Same thing with a linter. While the linter is supposed to encode best practices, code doesn't exist in a vacuum and had a context. For every linting rule, there is probably a certain number of good reasons to break them.

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

#213

Post by klyrs »

hatmatrix wrote: post #188
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

If you know the first value is truthy, sure.

  x = condition() and [] or True
is not equivalent to

  x = [] if condition() else True
Now, I have seen a genuine application of `X and A or B` before. That occurs when you're checking a condition before, say, popping from a list -- but if the list is empty, you still want a default value.

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

#214

Post by pierrebai »

inanutshellus wrote: post #193
Uberphallus wrote: post #189

Earlier quoted context omitted.

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

The "before" is what value is returned, the "after" is whether it should be returned. In your case you were conditionally choosing a manipulated return value for x and didn't care at all about filtering the list. Here's one with both: [x if x > y else x*2 for x in a if x % 2 == 0] ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ return x as... filter down to only... x or x*2 even 'x's There's not really a semantically logical place…

The point is not that we're idiots who don't know the language, but that functional-style ordering does not align with human cognitive cues.

The problem is that functional-style fails to separate essential bits and fails to give strong visual clues where each bits begins and ends.

That is why the old imperative style is clearer. Compare:

    for i in container:
        do something with i
and

    [do something with i for i in container]
One has a clear separation of loop and action, the other requires scanning for the "for i" in the middle. This generalize to other similar construct, and the Python ternary operator has the same flaw. The imperative if / else version clearly separate alternatives on separate lines.

IMO, syntax design should always try to learn from the imperative style and always strive to produce a syntax that clearly separate each logical item in a compound statement, and using different lines is one of the best for us human to visually grok.

(That's why even Lisper will often format their code to separate bits on different lines!)

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

#215

Post by klyrs »

ghgr wrote: post #140
_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)

Did you try that out in a REPL before posting? You should.

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

#216

Post by Chris2048 »

MathMonkeyMan wrote: post #144

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…

> For me, it's whatever I need to do to get through code review without arguing too much.

I agree with this. It takes a lot of context to truly understand another's code so reviews are just smoke & style checks, not real logic scrutiny like a kernel dev might do - in most cases businesses aren't willing to accept the true cost of such a review; I think the same is true of KT.

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

disagree. wrt pep-8 stuff, devs should be using their own linters before code is properly committed and for review. CI checks are easy to add and manage a quick/easy rebuke for the dev that doesn't bother.

For other style lints, tools that standardise trivial things (style w/ black, orderings w/ isort) reduce arguments and establish a consistent style. Code in whatever style you like, just standardise it for consumption. devs then argue at a higher level instead: over linter parameters.

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

#217

Post by fogof »

MathMonkeyMan wrote: post #144

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…

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

Well as he states, these checks are not turned on by default. I have trouble seeing why someone who liked these extensions enough to turn them on manually would feel condescended to by them.

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

#218

Post by PEJOE »

klyrs wrote: post #53
PEJOE wrote: post #18

Earlier quoted context omitted.

I agree, but to fair to the author I do not think the vast majority of people are implementing thread pools in python. I also think there were good reasons the author's linters were left as optional, and its probably not because everyone thought they were great ideas.

> I agree, but to fair to the author I do not think the vast majority of people are implementing thread pools in python. This trope needs to die. While loops are a basic language feature. A thread pool is one very specific example of where that language feature is necessary. Every very specific example is trivially dismissed with "the vast majority of of people aren't doing that very specific thing." It's the laziest…

Did you read the second half of my post? Did you read the authors post at all?

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

#220

Post by NwtnsMthd »

karatinversion wrote: post #139
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.

Thank you! For years I've tried to figure out how to chain the Python ternary operator while maintaining readability, and here it is!
Post reply on HN