Hacker News Reader

Comment by wallscratch | Hacker News Reader

I like how python’s indentation scheme makes code look nearer, but I find it scary in the following case:

for i in range(0, m):

    for j in range(0, n):

        doInner()

    doOuter()

A single tab here in the 4th line produces syntactically correct but logically incorrect code. I find this scary.

I guess it would be easy to just write your own preprocessor that requires curly braces everywhere and removes them for the python interpreter, but eh.

View on HN

Yeah, I don't like Python's approach in re syntax either.

In addition to your example, it backfires for things like multiline formulas (need to add parentheses or escapes) or lambdas.

Braces (or even 'end' like ruby) would be much more practical.

This example seems contrived. I used to swear by clean demarcations of expressions because of this logic, but in practice the return values of nested expressions are so rarely the same, and always reviewed before merge, with at least some kind of test or that would make this obvious, it would be almost unnoticeable.

For example :

    for i in range(0, m) : 
      for j in range(0, n) : 
         ... inner ... 
      ... outer ...

If `...inner...` is dedented then you will almost certainly get a compilation error since it is referencing `j`. If `j` is not referenced at all, you'll get a linter error saying "unused variable, j".

Additionally, you probably wouldn't want to write nested for-loops anyway, but something like flattening the inner loop into a return value.

> If `...inner...` is dedented

The problem usually isn’t …inner… being dedented, but …outer… being indented. Which usually won’t produce an error, since anything that could be in …outer… could also be in …inner… without error.

> Additionally, you probably wouldn’t want to write nested for-loops anyway, but something like flattening the inner loop into a return value.

Nested for-loops aren’t uncommon in real-world code. And, I…am not sure what you are saying here. Loops are imperative constructs, not return values.

Since Python scopes lexical variables to the function instead of the block, `j` is in scope for every line of `... outer ...`. So de-denting the last line of inner doesn't trigger a NameError, even for new bindings which were introduced within `... inner ...`.

Is this really different from braces? If you have

    for i in range(0, n) {
        for i in range(0, n) {
            doInner()
        }
        doOuter()
    }

and you accidentally move the first closing brace below the next line, precisely the same will happen.

In Python the mistake involves using the wrong invisible characters. It's totally bonkers.

Spaces are visible, unless they're at the end of a line.

If you do that, the indentation will be clearly wrong/mismatched and a compiler (or linter) can bark about it. No such possibility in python.

More likely the IDE just auto-indents the errant line and the programmer is still none-the-wiser.

Also you need white space diffs to be turned on to spot this change in code review, and this is particularly bad if indentation changed for another reason.

To be fair, you probably always want whitespace diffs turned on if reviewing Python, since indentation is meaningful.

Won’t there be an indentation error on line 3?

Reply on news.ycombinator.com