On 20/03/2017 14:32, Chris Angelico wrote:
On Tue, Mar 21, 2017 at 1:24 AM, BartC <b...@freeuk.com> wrote:
But it would be better IMO if tabs were used, with some scheme for
suggesting the tab width (or set of tab stops) that is recommended (eg. a
comment at the top).
If you absolutely have to, then sure, put a directive in some
machine-readable way at the top or bottom of the file. It's like the
coding cookie that Python follows - some editors also respect it. But
I would prefer to just use tabs *without* suggesting a width, because
each one represents *one indent*. Not a number of spaces. One
indentation level.
For leading tabs at the start of a new statement that wouldn't be a
problem. Changing the tab width shown just spreads out statements more,
or less, horizontally.
It works - there is no jarring misalignment - because each tab
corresponds to the same N spaces, whatever N happens to be.
But tabs are also used after statements, before comments for example, or
to line up elements in tables. Then it doesn't work, because tabs may
represent 1 to N spaces:
Using N=4, with 1 tab before each number:
(one, 1), #comment 1
(two, 2), #comment 2
(three, 3), #comment 3
Displayed using N=3:
(one, 1), #comment 1
(two, 2), #comment 2
(three, 3), #comment 3
Displayed using N=6:
(one, 1), #comment 1
(two, 2), #comment 2
(three, 3), #comment 3
Even tabs at the start of a line are sometimes using to line things up
with a previous line; here with N=4, and 5 tabs before B and C:
longfunctionname ( A, #comment 1
B, #comment 2
C) #comment 3
With N=2:
longfunctionname ( A, #comment 1
B, #comment 2
C) #comment 3
With N=8:
longfunctionname ( A, #comment 1
B, #comment 2
C) #comment 3
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
