>>There's already enough comflict between "(leading) tabs only" vs " (leading) space only" as well as conflict between camps who advoicate different indentation step sizse -- even before Python.
>
>It's actually quite simple. There are people who use spaces for indentation. There are people who use tabs but allow them to be displayed in any other width but three.
>
>And then there are people who will be spared.

One of the reasons that I ended up tine camp preferring spaces had to do with the trouble I dealt with different systems that may have different character sets (e.g. ASCII, EBCDIC, CDC-6/12, etc) and running into the "quirks" (and occasional buggy) translation tables. Tabs would often get "mangled" -- if I'm lucky they came out unscathed, but frequently tended to get mangled in various ways: "eaten" (i.e. maps into nothing), replaced with a space, "expanded" into a fixed number of spaces, "expanded" into variable number of spaces (number of spaces adjusted so that everything aligns on 8-character columns -- usually worked, except in the case where mapping function had a bug and failed on some edge cases so you result was either no spaces or an extra 8 spaces). Other characters that were subject to mangling included backslash, caret, curly braces, and square brackets -- so C source code generally got mangled rather badly (losing curly-brace was bad enough, but also having your indentation using tab getting altered made recovery difficult). And then there was the different ways that "newline" could be represented (e.g. CR only, LF only, CR+LF, LF+CR, 10 zero-bytes aligned on word boundary, etc.)...