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

121–130 of 262 posts

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

#121

Post by shultays »

apocolyps6 wrote: post #119

Most of the time when I see python ternary in the wild, it makes the code less readable, not more. Why not just define something like this if you want oneliners? def if_then_else(cond, true_case, false_case): if cond: return true_case return false_case x = if_then_else(condition, 4, 5)

Consider this:

    x = if_then_else(condition, calc1(), calc2())
Here it will call both calc1 and calc2 even though it will ignore one depending on condition. They might be expensive operations, or might have side effects that you don't want. The original code does not evaluate the part that is not used

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

#122

Post by ohazi »

> 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 things, but Python puts the 4 and the 5 so far away from each other that even I hate using it, especially when condition is a chained mess rather than just a function call.

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

#123

Post by dragonwriter »

> But here’s the reality: most code is not complex enough to warrant while loops, and most while loops are better written as for loops.

Hard disagree. Obviously, if the loop is a fixed number of iterations or iteration over a collection (which is trivial to identify by human inspection but probably not for a linter), a for loop is better but it is not uncommon to be looping until a (possibly compound) condition becomes true that cannot be expressed as a fixed number of iterations or (at least naturally; you can embed arbitrary complexity into a generator, though usually, absent unbounded recursion, that will just push the “while” down behind a layer of abstraction) as exhaustion of an iterable.

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

#124

Post by joatmon-snoo »

dragonwriter wrote: post #123

> But here’s the reality: most code is not complex enough to warrant while loops, and most while loops are better written as for loops. Hard disagree. Obviously, if the loop is a fixed number of iterations or iteration over a collection (which is trivial to identify by human inspection but probably not for a linter), a for loop is better but it is not uncommon to be looping until a (possibly compound) condition becom…

I've actually found that there are a number of situations where I really want:

  while True:
    ...
    if condition:
      break
    ...
and kinda wish there was a nicer syntax for this.

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

#125

Post by chakkepolja »

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…

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.

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

#126

Post by dragonwriter »

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

Honestly, the Python version is far more readable to me than the C, and that's even with close to a decade with C before encountering Python or any other language using that style.

Though Ruby’s unless modifier is often slightly better for readability.

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

#127

Post by ohazi »

joatmon-snoo wrote: post #124
dragonwriter wrote: post #123

> But here’s the reality: most code is not complex enough to warrant while loops, and most while loops are better written as for loops. Hard disagree. Obviously, if the loop is a fixed number of iterations or iteration over a collection (which is trivial to identify by human inspection but probably not for a linter), a for loop is better but it is not uncommon to be looping until a (possibly compound) condition becom…

I've actually found that there are a number of situations where I really want: while True: ... if condition: break ... and kinda wish there was a nicer syntax for this.

Rust has `loop {}` which I thought was weird at first, but also ended up use more than I would have expected.

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

#128

Post by mulmboy »

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' :…

Cheers for the history lesson - True and False really are relatively new in Python. I wonder how common that knowledge is.

http://python-history.blogspot.com/2013/11/the-history-of-bo...

https://www.python.org/dev/peps/pep-0285/

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

#129

Post by chriswarbo »

priansh wrote: post #56
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…

I shouldn't need to read the code extremely closely or repeatedly to have to figure out what it does when the while loop does it clearly (and in a bounded way that you can literally mathematically prove). Also, I would scream if some opinionated dev gone crazy with their linter added pylint disables and comments explaining it every time we use a while loop in our codebase. Why does the linter rule not, instead, check…

> I would scream if some opinionated dev gone crazy with their linter added pylint disables and comments explaining it every time we use a while loop in our codebase.

That sounds like a bad situation, but it completely depends on "every time we use a while loop". The entire point of lint checks is to reduce the occurrences of certain patterns (like while loops, in this case). This post is arguing that "every time we use a while loop" should ideally be the same as "never", in which case you're still correct, but vacuously so.

For a less controversial example, try running your comment through sed 's/while loop/eval/g'. There are certainly situations where 'eval' is the only way to do something; and other situations where 'eval' would be more readable/efficient (e.g. compared to writing a file and spawning a subprocess). Yet we go out of our way to minimise our reliance on 'eval', and I certainly wouldn't mind adding a pylint-disable comment for those times I use it (every few years).

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

#130

Post by dragonwriter »

forgingahead wrote: post #103
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

Agreed - relatedly, I really dislike one-liners in code because more often than not, it's done for the sake of being "clever" rather than having readable code for the next person to quickly skim and understand. I get that it's a "flex" or some sort, but honestly in production code my experience is that it reduces productivity. Programmers need a little more squinting to truly understand what that piece of code is doi…

> I really dislike one-liners in code

So...you should do more per line, since code is all one-liners, its just a choice of how many, so if you don't like them, you should reduce the number?

Post reply on HN