Deprecate tabs for indenting (was Re: Indenting with tabs vs spaces)

[Paul Boddie]

Courageous <jkraska at san.rr.com> wrote in message news:<n8js0ugnati1baeao1km4ovlb1qatr76rc at 4ax.com>...
> >Can you give an example of how spaces must creep in on continuation
> >lines?
> 
> ##--snip; not in particular the column-positioning of the "or". If
> ##        tabs are used here, it will be misaligned with other
> ##        tabstop stettings for certain
> 
>     if isinstance(f, future.Step)          or \
>        isinstance(f, future.Status)        or \

[...]

I'm pretty sure that this would go against Guido's style guide, which
just goes to show that that document is only prescriptive and is
followed only selectively by most Python coders. (Try claiming that to
someone who cites the "4 spaces for one indentation level" advice as
law, though!) Of course, a proportional font would cause the space
between the closing brackets and the "or" keywords to vary...

> ##--snip; in this case, the continuation line is lined up on the
> ##        string boundary to create some congruity between the code
> ##        and the message produced
> 
>     log.Fatal("Unexpected RETURN intercepted from user code.\n"
>               "This is almost certainly due to an inappropriate explicit\n"

[...]

I can actually understand why one would want to do this, but in my
tab-only private universe I move onto the next line after the opening
bracket:

  log.Fatal(
      "Unexpected RETURN...\n"
      "This is almost certainly..."

Note that I've simulated the effect of tabs because we all know that
you can't trust news/mail software to deliver them (and IE won't let
me enter any in the text box I'm using to compose this message), but
you can practise this with spaces too.

> ##--snip; here, like the or, the actions are put into a column.
> ##        simple actions, organized like this are both compact and
> ##        readable.
> 
>         if methodname==self.task.name:     methodname="-"
>         else:                              methodname=methodname[0:20]+"()"

[...]

This is similar to your first case. Personally, I'm not a huge fan of
doing this kind of thing.

> >                am aware that there's a lot of hostility to tab
> >usage in various open source projects, but that's really a consequence
> >of the tools around on many platforms today.
> 
> I don't think so. Even word will get fucked up if someone tweaks
> the positioning of the tabs in the ruler. The reason this problem
> doesn't make itself more evident is that the document carries its
> tabstops with it.

Well, I'd certainly be annoyed if the average word processor document
didn't retain its tabstop settings between editing sessions. Back in
the days when I used word processors and desktop publishers more, I
actually preferred to use frames to give me the layout for many of the
things which tabs could potentially have been used for, and one finds
out that spaces, tabs, margins and frames are a continuum of tools
each providing a tradeoff between being sufficient and convenient, and
being most appropriate. Tabs have the weakness that they don't always
move to a given horizontal location (even if that is the intention)
since the cursor might have moved past that location.

One might wonder what this has to do with Python. Given that Python
has, in a sense, decided against explicit structuring of code within
constructs (like having the equivalent of "frames" and playfully
illustrated in an XML example provided elsewhere in this thread), the
"blunt" tool of indentation is the only thing we have to instruct the
interpreter appropriately. Consequently, those of us who have the
tools available to us can choose to utilise tabs or spaces to perform
this instruction, and it seems to me that tabs are the better,
"sharper" tool, given that only leading indentation really matters to
the Python interpreter.

Of course, there's another interpretation of the tab as a structural
markup character, and this arises in things like tab-separated value
files; the tab *always* mandates movement to the next location or
"slot", and is analogous to the <td> element in HTML 3.2. By using
tabs in this fashion (which is possible at the start of a line), I
believe that one can be liberated from the fixed-font, "reserved
number of columns at the start of a line" mindset that has caused some
people to provocatively use the word "Fortran" when referring to
Python. (Even if that is going a bit too far!)

Paul