I think the problem he is describing--somewhat poorly--is when the "third space" just happens to match some other scope above, and therefore is syntactically valid, but not nested the way one initially thought.
Those kinds of problems can be hard to track down.
Never searched for 'hours' but it's been a annoyance before, usually related to copy/pasting. I certainly have run into the indent issue where my editor doesn't know what block it should be in but that's more emacs fault.
That said, I sure with python offered a totally optional end block thing. In many situations it would make things far more clear.
Exactly this. I've spent many hours on multiple hard-to-replicate bugs that turned out to be from a couple of lines at the end of a loop body that were indented to the wrong level after a refactor.
A third space can never align with another line since it will be an odd number of characters while indents are always even (or vice versa). If you are two chars off, well at some point you need to be responsible for your broken blocks.
I agree with the other person that says this doesn't really happen in the real world with a baseline developer and editor.
We now have three real-world counter examples just in this thread. And the hacker news crowd is relatively sophisticated technically--even for programmers in general.
"It isn't a problem for me, therefore it isn't a problem for anyone." just isn't a good way to reason about problems like this.
Sure, I'd never say a solution to a non-trivial issue was flawless. However, "a problem" is not very granular. I'd rather count this one in terms of centiproblems or milliproblems.
I don't see how. An editor can help you get indentations that are syntactically valid, but can't possibly know if the programmer intends the program below to print plain "foo" or both "foo" and "bar".
print("foo")
# x is false for the problem
if x:
do_something()
print("bar")
And to the parent who has written a lot of code but never had this problem, well, some people do.
Neophytes also have a lot of problems with matching braces, neither is a panacea to those folks. But one is easier to read and type for everyone else, for years to come.
It's a two space error in a trivial example that no editor can help with.
If the function is longer or their are a couple of additional levels of indentation, and it isn't a print statement, but some additional logic, it is a hard problem to spot.
Not true, look up indentation guides and whitespace visibility. Even my barebones editor has them and squashes ambiguity.
Still at some point one needs to be responsible for the code they write, braces or not. Braces are not a guaranteed solution either, if the author gives up complete responsibility.
Basically, this is a theoretical non-problem. The lack of braces pays back in readability every single day. Like +100 + -2, then complaining about the -2.
Those kinds of problems can be hard to track down.