Python handles globals badly.

[Marko Rauhamaa]

Ian Kelly <ian.g.kelly at gmail.com>:

> Emacs users with that setup would probably want the Python compiler to
> interpret a tab as eight spaces.

Which it does:

   Tabs are replaced (from left to right) by one to eight spaces such
   that the total number of characters up to and including the
   replacement is a multiple of eight (this is intended to be the same
   rule as used by Unix).

   <URL: https://docs.python.org/3/reference/lexical_analysis.html#lin
   e-structure>

although that definition has been rendered insignificant in Python 3 by
the footnote:

   Indentation is rejected as inconsistent if a source file mixes tabs
   and spaces in a way that makes the meaning dependent on the worth of
   a tab in spaces; a TabError is raised in that case.

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

That "innovation" has destroyed the TAB character. It won't be missed,
though.

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

Emacs didn't invent that scheme. That's how TABs worked in my childhood
across operating systems.

However, TABs were always problematic for other reasons. If you added
a space to the beginning of every line to shift everything to the right,
TABs caused a misalignment.


Marko