Non-Indented python

Tim Peters at
Fri Nov 30 20:57:20 CET 2001

[Michael Abbott]
> Please, please, it would be helpful if Python had a (configuration
> settable) option to reject tabs in all source.

Write a PEP -- in a later msg you expanded the scope of what you want, and
other people will want yet other gimmicks.  I've got no interest in it
myself (use -tt; use; use; don't let babies edit
your source code <wink>).

> ... [later] ...
> Is there a global option (I'm on WinNT) to make -tt the default?

No, but you can use an obvious one-liner .bat file to supply -tt instead of
running python.exe directly.

> P.S. Where is this documented?  I can't see any documentation of command
> line parameters in any of the standard documentation (,,
> etc) I have, so I presume that
> 	Python -h
> is all I've got to go on.

I think "that's it" on Windows.  Unix users have a wordier man page

> There doesn't seem to be an environment variable which can pre-set
> command line options, so I'll have to do something more tricksy to get
> -tt set by default.

A .bat file is easiest on Windows.

> Finally, when -t refers to "inconsistent tab usage", what exactly does
> this mean?

That there exists an adjacent pair of statements (not counting comments or
blank lines) such that the relative indentation of their initial lines
("more", "less", "same") differs if hard tabs are considered to be 4-space
gimmicks instead of 8-space gimmicks.  So, e.g., and where T is a hard tab
and S a space, this is inconsistent according to -t:


(they're both indented 8 if T is an 8-space gimmick, but the second is
indented less if T is 4).  This is not inconsistent according to -t:


because -t only looks at tab widths of 4 and 8, and both those lines are
indented the same (as each other) either way.   The last example is
inconsistent according to, which looks at all tab widths greater
than 0 (and those two lines are not indented the same (as each other) if,
e.g., a hard tab is a 2-space gimmick).

>  I would really like something like to treat tabs (and indeed all
> non-printing characters except for space and newline) as syntax errors
> wherever they appear in the source.

PEP, but it's so easy to write a little program to ensure this (on Unix it's
a grep one-liner) I doubt anyone will bother.  Note that Emacs users often
use form feed characters to mark the start of a function, so "all
non-printing characters" is too broad.

More information about the Python-list mailing list