Misplaced brackets seem like a thing from the past to me when we didn't have IDEs. I don't remember ever having a bug due to that.
I can't imagine how. Whitespace physically lays out the block structure on the screen; braces expect you to count and balance matching symbols, and possibly scan for them within other line noise.
Any reasonable language with braces has standard formatter that will just put each brace level on a different whitespace level.
But GGP was making a claim about the braces themselves solving the problem, and they clearly do not. The indentation automatically inserted by your tooling solves the problem. And it's at least as easy to communicate the intended block structure with colons and backspaces as with open braces and close braces, plus it doesn't waste lines (or invite bikeshedding) for the closing braces.
Brackets would allow the editor to autoindent the pasted code.
No choice is perfect.
I mean: you don't count the braces because your tooling counts them and makes the indentation match what Python would use anyway. If you had just created that indentation in the first place (which with a proper editor is at least as easy as typing the braces; you essentially type : instead of {, and backspace instead of } ) then you'd be in the same place, except without the extra punctuation noise (well, with half of it, because GvR thought the colons were a useful signal even if redundant).
I know that is mainly a beginner coding issue, but never having to deal with that issue was always one of the biggest advantages of python.
That said, I believe a lot of the stuff that was added in 3 and beyond (to make it more typesafe, accounting for unicode, etc) has made it a lot less readable over time. You can argue that it has made Python a better and safer language, but the pseudocode aspect has gotten worse. I kinda miss that.
And today with autofotnatters I think only Python is still vulnerable.
Yes, I can castle-[ to shift a block of code left or right, but this is not always problem-free nor is it automatic nor does it have any sense of where the indents should go.
Yes, there is a "format python properly" button which often errors out says "there is an indentation error in your python so I cannot automatically indent it"
Would I like to use better tooling? I present my .vim file as evidence. Am I using what they tell me is state of the art? yes. And in 2026, state of the art does not solve python indenting, because python indenting is inherently a broken paradigm
I don't know what to tell you. I use Vim and find it trivial to get the indentation right using my distro's stock config.
It usually only takes me a 1-5 seconds to fix the indentation when I copy/paste code that existed at a different indentation level. This is not something I'd complain about, personally.
I enjoy Python, but the significant whitespace is _not_ one of the reasons.
I genuinely don't understand how they manage this. Worst case, you paste at column 1, re-select and tab such that the baseline is appropriate for where you're pasting it, which is obvious. But more importantly, you shouldn't be copying and pasting unless you're proficient enough to fix such mistakes easily.
I also don't understand how it can be argued seriously that braces avoid the problem. If you'd paste at the wrong indentation level, why would you not equally well type the wrong number of braces?
Also, good automatic formatters (gofmt, rustfmt, etc) also indent along control flow lines, so without the braces you just changed a syntax error into a "hmm, this is acting really strangely" bug-hunt by using python.