also, 100% this.
I could care less what human-A did for his indenting, at least on C code. if the code works and compiles, I can FIX his indentation and not ruin a thing; only make it more readable.
there is no concept of a re-indent or auto-indent (such as found in emacs, for example) for python. you can't do it. because as I posted before about this: there are 2 things and they should never be mixed. one is a cue to the compiler what a block is, and the other is a cue to the HUMAN what a block is. and combining them is what guido fucked up, on.
in C, I can do whatever wild indenting I want and a re-indent can fix it so I can read it again. I got very used to that. code was ROBUST in this way, and humans can mess with the look of it without doing harm. if I move a block from some inline code to a nested routine, it always ALWAYS works. not so in python. in fact, I'm not even sure HOW to move a block from one level of indent to another with perfect safety. its just STUPID!!!! stupid beyond belief to those of us who have been writing code for decades (I'm mid 50's and have been doing software eng work since my teens).
part of me wants to add a feature to the language so I can add braces back again, then preproc the source to remove it as a phase before running the code. I know it won't be accepted by anyone in my company but it would restore sanity to my own python projects, at least.
imagine a source code control system where check-out gets you those braces, you do your edits and each time you save the file to local git or svn (etc) it removes the bad chars and makes it 'real python' again so you can run it. that way you kind of have it both ways and editing, at least, is now more safe.