New Ways to Be Told That Your Python Code Is Bad • Hacker News Board

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

#41

Post by PeterisP » Fri, Sep 03, 2021, 2:13 AM UTC

SkipperCat wrote: post #5

Tools that enforce "expert level" coding standards do make code more concise, but also less comprehendible for the less experienced developers. I never saw the harm in four lines of code instead of one, especially when it's much more readable.

I agree with the general concept of "Tools that enforce "expert level" coding standards do make code more concise, but also less comprehendible for the less experienced developers." but this does not seem applicable here - it's not "expert level" coding, the suggested method is obviously readable to anyone who writes Python and is something that a programmer who has never used Python would learn in their first day of learning Python, it's not an advanced concept.

Probably the whole concept of idiomatic Python is that there shouldn't be different styles of Python to which you graduate according to skill or experience, but rather that the simple, readable way of writing things should be done by everyone, always, from novices to experts. Code-golfing with dense weirdness would be "anti-Pythonic" but this ternary expression would be readable even for if someone who's never seen Python would read it as pseudocode in some theoretical CS paper.

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

#42

Post by joshuamorton » Fri, Sep 03, 2021, 2:13 AM UTC

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…

You don't need the walrus operator, as keyword args are valid.

    f(x=a if b else c)

Should be valid. All the walrus gets you is making the x "infect" the surrounding namespace which is surprising.

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

#43

Post by notatoad » Fri, Sep 03, 2021, 2:14 AM UTC

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

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

#44

Post by mattbuilds » Fri, Sep 03, 2021, 2:15 AM UTC

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

I closed the article at that exact spot.

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

#45

Post by Zababa » Fri, Sep 03, 2021, 2:15 AM UTC

juanci_to wrote: post #12

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

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.

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

#46

Post by notatoad » Fri, Sep 03, 2021, 2:18 AM UTC

SkipperCat wrote: post #5

Tools that enforce "expert level" coding standards do make code more concise, but also less comprehendible for the less experienced developers. I never saw the harm in four lines of code instead of one, especially when it's much more readable.

in general i agree, but i'm not sure what you're referring to as "expert level" here - if it's ternary operations, those a pretty basic concept, and i don't think there's a clear argument to be made that they're more or less readable than expanding out the if statements, it mostly just comes down to preference.

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

#47

Post by markrages » Fri, Sep 03, 2021, 2:20 AM UTC

chriswarbo wrote: post #38

scythe wrote: 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?

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.

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

#48

Post by joshuamorton » Fri, Sep 03, 2021, 2:21 AM UTC

juanci_to wrote: post #12

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

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

To add to the cacaphony of counterarguments to this, this can introduce nonobvious bugs when refactoring.

If the condition-guarded statement is nontrivial and you remove the assignment, everything stays valid. If otoh you use a ternary or

    if x:
        y = 1
    else:
        y = 2

If you now delete the else block or something (like the assignment from a larger else block), a linter can warn you that y is undefined. Otherwise you'd need a test to ensure correctness.

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

#49

Post by markrages » Fri, Sep 03, 2021, 2:23 AM UTC

tempest_ wrote: post #37

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.

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

I think that's brain damage from years of embedded C.

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

#50

Post by priansh » Fri, Sep 03, 2021, 2:24 AM UTC

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 disapproving of while loops in the article seems to stem from the author assuming while loops are "unbounded." This is absolutely, completely, totally false and there are entire branches of reasoning dedicated towards observing the bounded-ness of while loops. Most colleges include this in their curriculums and you usually have to learn to prove (via induction) the variants and invariants surrounding your loop before you can pass basic classes. It's even more ridiculous that, in the same breath, the author assumes for loops are guaranteed to complete execution. I can disprove this in two lines of code and two braincells:

  for x in infinite_generator():
    do_something()

This is also the general structure that message-queue libraries like Kafka, RabbitMQ etc take with their python code. Not to mention that, in many programming languages, for-loops are actually implemented as while loops behind the scenes.

I'll cede that it's easier to write unbounded code with while loops than for loops, but this is programmer error that can be pretty easily avoided by simply being a teensy tiny bit careful (and can be easily corrected). I'd also argue that the majority of these cases where while loops can be substituted by for loops, are also cases where writing a while loop is much simpler than trying to convert into a for loop. (Besides, you could make any of these arguments about recursion.)

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

This is also a lie, Excel absolutely has infinite loops, it just yells at you when you do it. The equivalent of this in programming is a linter. Instead of just screaming fire every time the user writes a perfectly fine while loop, why not concentrate your efforts on identifying unbounded loops and introducing a linter rule for that?

Honestly, it's absolutely terrifying to me that someone contributing to the predominant linter for a major programming language not only wholeheartedly believes while loops are always unbounded and usually evil, but also managed to get this introduced (and presumably approved) by reviewers of this linter, and then proceeded to gloat about it on HackerNews. It comes as no shock to me that most people I've worked with disable pylint in their editors if they're this unreliable with their review process.