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.

The important issue is which solution is the best given the trade offs. Acceptance of nothing less than a flawless one is not a path forward.

Sold! As long as you admit that there is a problem and tradeoffs, then I'm fine with where this conversation is ending.

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.

These kind of problems can be solved or avoided altogether by a decent editor.

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.

That's a two space error and easy to see.

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

I write python all the time, with editors that support this. People do encounter this problem.

You'll also note that I've never claimed braces were better, I'm just trying to explain OP's pont.

You may not encounter it, but "Hey it works for me" is not a legitimate answer.

> Those kinds of problems can be hard to track down.

In many years of writing Python I have not once encountered this issue. And I didn't always use four spaces...

Not to mention, who hits the spacebar four times for their indentation? Actually. Do people do that?

I frequently have to when copy/pasting code in VS Code and it assumes the wrong indentation level.

You could select the whole pasted part and press tab or shift+tab to change its indentation level.

To back this up, I was at a place where vim on my Mac and the Windows editor on the machine of one of the people consuming my code would somehow munge the spacing (tabs-to-spaces, or summat).

Point is, I'd see this problem constantly until I figured it out. And not once did it take more than a few minutes to fix it because, as you point out, it shows you where the problem is. And if you use PyCharm, or VS Code with Python extension, or a raft of any other editors, it'll bark at you long before you try and run the code, with circles and arrows, and a paragraph on the back of each one explaining the problem.

So, yeah, the author is making shit up. And needs to learn about what the Tab key does.

Doesn't even need to be a big heavy editor. I use the lightweight Geany and even it has indentation guides and whitespace visibility. Even so, I could probably fix such a problem without it.

Do you mean using spaces or using the space bar? 4 spaces is standard but the editor should take care of that with tab that results in 4 spaces. An actual tab is just plain wrong. It is allowed of course, but those developers are wrong for doing so.