Sure, whitespace is significant, but I've never had it break easily or be "brittle" as you say
The Jabber Python MSN transport shipped with an intent bug in an error path for several releases. The error path was never hit on the developer's test machine, but always hit for me because I didn't install one of the optional libraries. The error was caused by mixing tabs and spaces, and so looked correct in the editor, but Python happened to interpret a tab as a different number of spaces to the editor[1] and so it ended up doing something different.
This is what people mean when they call it fragile. You can introduce bugs as a result, but never see them unless you hit the code path in question (this, by the way, is a common source of exploitable bugs in all languages: code paths that are rarely hit that contain bugs, and Python makes them so easy to introduce). Meanwhile, in any language that either enforced the no-mixing-tabs-and-spaces rule with static checking[2], or which had a block delimiter character, these would be caught statically at parse time.
I can think of no other language where such a high proportion of code that I've run that has shipped as working releases has needed me to fix it before it will even start. As far as I can tell, all of the refugees from VB6 ended up writing shoddy Python code. Is it the language's fault? Well, it certainly doesn't help. I've been asking Python programmers for the last year what an else clause on a for loop meant. Last Friday, one gave the correct answer for the first time. Why do I know what it means? Because a person who wrote some (and shipped) some code using it apparently didn't...
[1] Ignoring Python's general hostility to using the character that means 'indent by one level' for indents, any language with significant whitespace that doesn't error when you have a line that has both tabs and spaces at the start of a line is broken.
[2] I believe that Python now has an option to check this. It should have been on by default since the first release.