Inconsistencies with tab/space indentation between Cygwin/Win32?

[Nobody]

On Thu, 04 Aug 2011 13:55:37 +0930, Christian Gelinek wrote:

> I find it at least confusing to read that Python expects a tab size of 8 but
> at the same time uses 4 spaces for one indent level. Or maybe I am
> completely on the wron track here?

4-column indents are a convention, not a rule. You can use however many
columns you like, and you don't even need to be consistent about it; you
can use 2 columns for one "block" and 4 columns for another. Python only
cares about "indented more than the previous line" and "indented to a
depth matching an outer level of the code".

8-column tab stops are a rule, due to it being such a long-standing
convention that some software and hardware has 8-column tab stops
hardwired (and anything which allows tab stops to be configured normally
defaults to 8 columns).

> Any ideas on how to get the thing to run under (real) Windows, hopefully
> without having to edit existing sources of people who left our company ages
> ago?

The only time you'll have problems is if you copy-and-paste code which was
written using a mix of tabs and spaces and which assumed a different tab
width. If code only ever uses tabs, the tab width doesn't matter. If code
uses a mix of tabs and spaces and it actually works, it's correct
according to Python's 8-column tab stops, even if that's not how the
programmer's editor was set up. Also, copying blocks of code which start
and end at the top-level (i.e. without indentation) will work regardless.

Where it fails is if you copy indented code from e.g. a file which used a
mix of spaces and 4-column tabs into a file which uses 8-column tabs.

If you have existing code which uses a mix of tabs and spaces where tabs
aren't 8 columns (or you aren't sure that they're 8 columns), your best
bet is to reformat the code to avoid using tabs (on Unix: "pr -t -e", or
"pr -t -e4" for 4-column tabs).