Python handles globals badly.

Ian Kelly ian.g.kelly at
Fri Sep 11 07:07:17 CEST 2015

On Thu, Sep 10, 2015 at 10:34 PM, Marko Rauhamaa <marko at> wrote:
> Ian Kelly <ian.g.kelly at>:
>> You can use tabs *or* spaces. If you want to mix the two, then there
>> would need to be some official decision made about how many spaces
>> compose a tab, and then everybody who wants to use tabs would have to
>> configure their editors to conform to that decision, or risk breaking
>> their code. Some people like to indent two spaces. Some people like to
>> indent four spaces. On the other hand, the de facto standard for
>> terminal tab width is eight spaces. However, virtually nobody prefers
>> eight spaces of indentation. So the question is which standard are you
>> going to adopt, and which groups are you going to upset?
> Indentation preferences and the interpretation of TABs are two separate
> things.
> For example, in the default emacs configuration, the C indentation
> levels go like this:
>    SPC SPC
>    TAB
> etc. The TAB *key* is a command that makes emacs indent with a mix of
> spaces and TABs.

That's all true but is tangential to my point. Emacs users with that
setup would probably want the Python compiler to interpret a tab as
eight spaces. On the other hand, the major benefit that is often
touted for indentation using tab characters is that the reader can set
their tab width and read the code with their preferred indentation
(this fails however when using mixed tabs and spaces as in that Emacs
scheme). Such users typically use one tab character as one level of
indentation and would presumably prefer to have those tab characters
interpreted as two or four spaces, not eight.

If we're forced to choose a canonical tab width, both groups can't
win. (Of course that Emacs indentation scheme already doesn't work for
Python, but then the only possible benefit I can see to using it is a
mild compression of the source code, an economy of disk space that
really isn't necessary in this day and age.)

More information about the Python-list mailing list