> You will shoot yourself in the foot less often with Lisp parens than you might with Python whitespace.

I'm not letting that stand ;-)

In my experience Python's whitespace generally removes sources of scope/block errors compared to parenthesis and curly-based languages

> unless you have a Python plugin that has block movement shortcuts

Not sure what this means. The only support I need in an editor is the ability to use tab and shift tab on blocks of text to change the indentation level. It's visually obvious when code is correctly indented.

> "It's visually obvious when code is correctly indented. "

Not when the beginning of the code block isn't on screen.

And more to the earlier point, configuring your editor to jump to the beginning from the end or the end from the beginning of a particular block of code going to be trickier than the equivalent in even vim for lisp, which is simply %

(And vim isn't even a particularly good editor for lisp, but out of the box unconfigured, it's better at lisp than it is at python.. % isn't even lisp specific functionality, lisp just happens to use balanced parenthesis which is something nearly every serious text editor happens to handle in a reasonably robust way, because balanced parens are generally useful in many languages, including python!)

> Not when the beginning of the code block isn't on screen.

The length of your code blocks terrify me. :)

It doesn't take more than two dozen or so lines depending on the window arrangement. Nothing truly excessive. Alternatively, viewing the entire code block might mean scrolling up.

If you want scary, check out GNU's implementation of `cat`. I think they hit ten nested indentation levels. Though, because that's C, you can at least jump between the beginning and end of each level by having your editor jump to the matching {}.

> Not sure what this means. The only support I need in an editor is the ability to use tab and shift tab on blocks of text to change the indentation level. It's visually obvious when code is correctly indented.

In Emacs you can use C-M-f and C-M-b to move back and forth over / select paren/bracket/brace delimited blocks, or in vi you can use %, both with 0 configuration in a language-unaware state. If you're editing C or Lisp or whatever, these generic commands are useful. Editors don't tend to have move-to-next-less-indented-line (and similar) commands outside of Python modes or similar, in my experience, and even if they did, they'd need a bit more work than that to work properly because of indenting subexpressions.

> It's visually obvious when code is correctly indented

Not always, in my experience. I’ve lost many hours to debugging only to realise some piece of code was misindented. It doesn’t happen often and usually when code is being moved around, but when it does, its been painful.

The worst I have seen is: There is a merge commit (fixing conflicts) and then, a "if" condition get accidentally de-indented (compared to what it should be), and now this bug is completely invisible and the code will run just fine... (until you figure out what's going on)

Having seen many instances of someone not pasting the full function on a move, the "whitespace defines otherwise invisible changes of scope" is not something that endears me to the language.

I almost buy that it encourages simpler blocks, since complicated ones are impossible to parse out rather quickly. But my later reviews shows it doesn't remove them.