Python indentation (3 spaces)
On Mon, Oct 15, 2018 at 1:35 AM Grant Edwards <grant.b.edwards at gmail.com> wrote:
> On 2018-10-14, Christian Gollwitzer <auriocus at gmx.de> wrote:
> > Am 14.10.18 um 02:45 schrieb Grant Edwards:
> >> On 2018-10-13, Peter J. Holzer <hjp-python at hjp.at> wrote:
> >>>> For "just use tabs" to work, all of those tools would have to
> >>>> magically recognize that they're looking at Python source and adjust
> >>>> the tab size accordingly. That isn't going to happen.
> >>> Well, no. The idea of "just use tabs" isn't have a different tab width
> >>> per language, but a different tab width per user.
> >> You work in a different environment than I do. for me, tab width
> >> varies from one project to another (sometimes even in the same
> >> language). I don't get to pick just one tab width.
> > But if you use only tabs for indentation, the tab width setting simply
> > does not matter.
> > There is a disadvantage only if you try to align something which is NOT
> > an indentation level, e.g. when there are big string constants or list
> > constants etc.
> Exactly. In my experience, people who use tabs for indentation always
> end up using them for other things as well: aligning comments or columns
> in data tables, etc.
Well, I don't, and I DO use tabs for indentation. So how about we
restrict this discussion to indentation, and not worry about other
things people might also use tabs for?
Tabs for indentation have semantic meaning. Top-level has zero tabs.
One indentation level is represented by one tab. Two indentation
levels? Two tabs. It's about as perfect a representation as you could
hope for. If you like your indentation levels to be as wide as four
spaces, you can have that. I could have them at eight, and it wouldn't
make a difference. And if someone messes up their code by using tabs
to align all their comments, reject that code at code review time.
This ain't rocket science.