Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 8, 2018 at 10:31 AM Terry Reedy <tjreedy at udel.edu> wrote:
>
> On 10/7/2018 2:35 PM, Ryan Johnson wrote:
>
> > The logic is that all the text editors that are designed to work with Python code will KNOW to replace tab input with 3 characters, while still parsing the \t tab character as 4 characters;
>
> What do you mean by 'parsing a tab character as 4 characters'?  If the
> editor *converts* the tab to k spaces in its buffer, then k must be the
> same number as when the user types a tab, and there is no tab left to
> worry about.  If the editor put the tab into its buffer (and saves it
> with tabs), then what users on particular display devices depends on
> what the device does with tabs.
>
> Theoretically, all tabs might seem like a good idea, but since 0 spaces,
> 1/2 inch, and 8 spaces are possible display results, in addition to a
> users custom setting, this does not work except in a circumscribed
> environment.  That leaves space indents and no tabs except in strings
> where needed.
>

TBH, I think that tab width should be up to the display, just like the
font. You're allowed to view code in any font that makes sense for
you, and you should be able to view code with any indentation that
makes sense for you. If someone submits code and says "it looks
tidiest in Times New Roman 12/10pt", I'm sure you'd recommend making
sure it doesn't matter [1]; if someone submits code and says "you have
to set your tabs equal to 5 spaces or it looks ugly", you'd say the
same, right?

How wide my indents are on my screen shouldn't influence your screen
or your choices.

ChrisA

[1] eg the last of the Pet Peeves
https://www.python.org/dev/peps/pep-0008/#whitespace-in-expressions-and-statements