Hacker News Reader

Comment by chriswarbo | Hacker News Reader

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 which generated (x, f(x), f(f(x)), ...), but I couldn't find one in Python's builtins:

    scales = takewhile(
        lambda n: n > 0.1,
        iterate(5, lambda x: x / 2)
    )
    map(do_stuff, scales)

View on HN

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 if the while loop is unbounded and warn the user of that? Surely screaming fire when there's an actual fire is better than screaming fire at the first sign of smoke.

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

> Why does the linter rule not, instead, check if the while loop is unbounded and warn the user of that?

Indeed, the linter only needs to incorporate of the many known solutions to the halting problem.

unBounded = null

Poe's law demonstrated.

Indeed, though in a language designed for this style of programming, the idea behind that final example in the GP comment works fine. A Haskell version might look something like this:

    iterate (/2) 5.0
      & takeWhile (>0.1)
      & map do_stuff

The `iterate` generates the infinite sequence, the `takeWhile` specifies how much of it to use, and then we do stuff with each element.

This is arguably a little nicer than the while loop since it exposes the real sequence of values you’re working with more explicitly, but at the very least it is comparably simple in its appearance. The Python version in the GP comment looks bad mostly because of the clumsy lambda syntax.

Reply on news.ycombinator.com