>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.)...

Ouch. Funny though, I had the same experience, in a way - I shuffled files between CP/M, PDP, VAX, several flavors of DOS, Xenix and a bunch of linuxes. The aforementioned way I probably travelled in the opposite direction, because pretty much anything could be scrambled in unpredictable ways, but tabs remained.

The worst case is when any spacer would edit my code in her own editor and use her own idea of indentation, and then I'd have to delete oodles of spaces... That's when I learned not to worry and love the beautifier. Nowadays I run it after about six lines of code I write. It's not just second nature, it's a serious contender for first place.

Now the sixpack question: is there a beautifier for Python and how intelligent does it have to be?