> There are plenty of times in Python and YAML I cannot visually figure out where some block ends.

To match the start of a Python block (with possibly other blocks nested within it) to its end: start at the (non-whitespace) column where the opening line begins, and go straight down until you find another line that starts in that column (or EOF).

Or you use an editor (or plugin) that just knows how to do this, just as you would with the balanced brackets. cf. https://vi.stackexchange.com/questions/7262 .

You can also just... not nest so deeply, or write so long. My functions rarely have more than ten lines are are usually not even inside classes; and I don't generally need more than three levels of indentation (that gets you, for example, a test within a loop within a function — which might well be better done with a comprehension anyway).

> XML prevents this by explictly stating what element was just closed.

Only for elements that cannot, even indirectly, contain other elements of the same element name. And for this limited safeguard, you double up every element name even in cases where it would otherwise be completely clear (which contributes to visual noise as the sibling comment points out). Of course, XML is designed for things that inherently need to be deeply nested. Your code usually doesn't.

https://en.wikipedia.org/wiki/Turing_(programming_language) tried the same idea. It didn't catch on.

> There are plenty of times in Python and YAML I cannot visually figure out where some block ends.

I might understand this objection for YAML, but for python, it's very clear: a block ends whenever the content on the next line is indented by four fewer spaces. (And lists and dicts are explicitly closed with brackets)

If you're talking about matching block starts to ends, then that's just as bad in json, if not worse; without an editor that does brace coloring, it's almost impossible to eyeball which brace goes to which block without indenting (which is the whole point of significant whitespace).

> Deeply nested XML, provided the elements don't have some 300 character set of attributes all jammed into the opening element, is vastly easier to read than YAML.

Not really. More often than not, tags are visual noise that make it harder to scan for the actual content.

I have to read a lot of deeply nested XML for part of my job, and I wrote a parser to display it as YAML precisely because it's more readable. If your data is so convoluted that you need xml tags to make sense of it, that's usually a sign you need to either refactor it, or provide a proper display tool.