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