Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #74066 > unrolled thread

Re: PEP8 and 4 spaces

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: PEP8 and 4 spaces Ben Finney <ben@benfinney.id.au> - 2014-07-07 11:00 +1000
    Re: PEP8 and 4 spaces Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-07 02:28 +0000
      Re: PEP8 and 4 spaces Chris Angelico <rosuav@gmail.com> - 2014-07-07 12:50 +1000
    Re: PEP8 and 4 spaces Dan Sommers <dan@tombstonezero.net> - 2014-07-07 05:35 +0000
      Re: PEP8 and 4 spaces Ben Finney <ben@benfinney.id.au> - 2014-07-08 11:22 +1000
        Re: PEP8 and 4 spaces wxjmfauth@gmail.com - 2014-07-08 00:03 -0700
        Re: PEP8 and 4 spaces Steven D'Aprano <steve@pearwood.info> - 2014-07-08 08:48 +0000
          Re: PEP8 and 4 spaces Chris Angelico <rosuav@gmail.com> - 2014-07-08 19:05 +1000
          Re: PEP8 and 4 spaces Marko Rauhamaa <marko@pacujo.net> - 2014-07-08 12:09 +0300
            Re: PEP8 and 4 spaces Chris Angelico <rosuav@gmail.com> - 2014-07-08 20:28 +1000
              Re: PEP8 and 4 spaces Marko Rauhamaa <marko@pacujo.net> - 2014-07-08 14:13 +0300
                Re: PEP8 and 4 spaces Chris Angelico <rosuav@gmail.com> - 2014-07-08 21:37 +1000
          Re: PEP8 and 4 spaces Ben Finney <ben@benfinney.id.au> - 2014-07-09 12:41 +1000
            Re: PEP8 and 4 spaces wxjmfauth@gmail.com - 2014-07-09 01:19 -0700

#74066 — Re: PEP8 and 4 spaces

Dan Stromberg <drsalists@gmail.com> writes:

> But I finally acknowledged that some very smart people don't
> understand tabs, or don't want to learn how to use them.

One day, you may reach the further realisation that those same very
smart people *do* understand tabs, and *do* know how to use them — and
nevertheless choose not to put them in source code, for good reasons.

> Also, I figured out how to get python files to use spaces and
> Makefile's to use tabs, using some slight vim configuration.

The makefile syntax is one of the excellent examples of why it's a
terrible idea to use tab characters in source code. It's also an
excellent example of how a poor design decision (a line beginning with
U+0020 SPACE is semantically different from a line beginning with U+0009
CHARACTER TABULATION) can be irrevocable – the syntax can't be changed
now, without breaking compatibility for countless makefiles out there
already – and cause endless confusion and wasted effort dealing with it.

Using a mature, well-customised, language-agnostic programmer's editor
does make it much better: Vim and Emacs can both seamlessly handle “tabs
are forbidden by default” as a configuration choice, along with “tabs
are necessary in make files, using spaces in the wrong place is an
error” at the same time.

> So I'm using 4 spaces now.
>
> It's nice not having to ignore the relevant pep8 and pylint warnings
> anymore.  And I don't miss tabs nearly as much as I thought I would.
> In fact, I'm not sure I miss them at all.

Hooray! Welcome to the light :-)

-- 
 \                   “The best ad-libs are rehearsed.” —Graham Kennedy |
  `\                                                                   |
_o__)                                                                  |
Ben Finney

[toc] | [next] | [standalone]

#74069

On Mon, 07 Jul 2014 11:00:59 +1000, Ben Finney wrote:

> The makefile syntax is one of the excellent examples of why it's a
> terrible idea to use tab characters in source code.

Hmmm... I'm not sure that conclusion follows. I think that makefile 
syntax is an example of why it is a terrible idea to give spaces and tabs 
different semantics, not that tabs themselves are harmful.


> It's also an
> excellent example of how a poor design decision (a line beginning with
> U+0020 SPACE is semantically different from a line beginning with U+0009
> CHARACTER TABULATION) can be irrevocable

Yes. Design your public APIs cleanly and clearly from the start.

The story of makefiles is a warning of the dark side to "release early, 
release often", and the dangers of using alpha software in production:

[quote]
Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried 
either, so I figured this would be a good excuse to learn. After getting 
myself snarled up with my first stab at Lex, I just did something simple 
with the pattern newline-tab. It worked, it stayed. And then a few weeks 
later I had a user population of about a dozen, most of them friends, and 
I didn't want to screw up my embedded base. The rest, sadly, is history.
-- Stuart Feldman 
[end quote]




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#74072

On Mon, Jul 7, 2014 at 12:28 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> The story of makefiles is a warning of the dark side to "release early,
> release often", and the dangers of using alpha software in production:
>
> [quote]
> Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried
> either, so I figured this would be a good excuse to learn. After getting
> myself snarled up with my first stab at Lex, I just did something simple
> with the pattern newline-tab. It worked, it stayed. And then a few weeks
> later I had a user population of about a dozen, most of them friends, and
> I didn't want to screw up my embedded base. The rest, sadly, is history.
> -- Stuart Feldman
> [end quote]

Perhaps. Or perhaps it's a warning about the importance of version 0
of a piece of software: you "release early, release often", but you
start with version 0.1, where the standard backward compat guarantees
don't hold. You get some feedback, and then when you finally release
version 1.0, you start promising not to mess people's stuff up; but
before that, anything might change.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74077

On Mon, 07 Jul 2014 11:00:59 +1000, Ben Finney wrote:

> The makefile syntax is one of the excellent examples of why it's a
> terrible idea to use tab characters in source code. It's also an
> excellent example of how a poor design decision (a line beginning with
> U+0020 SPACE is semantically different from a line beginning with
> U+0009 CHARACTER TABULATION) can be irrevocable – the syntax can't be
> changed now, without breaking compatibility for countless makefiles
> out there already – and cause endless confusion and wasted effort
> dealing with it.

When makefile syntax came into being, there were ASCII TAB characters,
with a value of 9, and ASCII SPC characters, with a value of 32 (and
there may not even have been those).  The former is a "control"
character, which has specific semantics associated with it; the latter
is a "printable" character, which is usually printed and interpreted as
itself (although in this particular case, the printed representation is
hard to see on most output devices).

This mailing list doesn't seem to mind that lines beginning with ASCII
SPC characters are semantically different from lines beginning with
ASCII LF characters, although many detractors of Python seem unduly
fixated on it.

[toc] | [prev] | [next] | [standalone]

#74146

Dan Sommers <dan@tombstonezero.net> writes:

> On Mon, 07 Jul 2014 11:00:59 +1000, Ben Finney wrote:
>
> > […] a poor design decision (a line beginning with U+0020 SPACE is
> > semantically different from a line beginning with U+0009 CHARACTER
> > TABULATION) can be irrevocable – the syntax can't be changed now,
> > without breaking compatibility for countless makefiles out there
> > already – and cause endless confusion and wasted effort dealing with
> > it.
>
> When makefile syntax came into being, there were ASCII TAB characters,
> with a value of 9, and ASCII SPC characters, with a value of 32 (and
> there may not even have been those).

A group of (a particular amount of) U+0020 characters is visually
indistinguishable from a U+0009 character, when the default semantics
are applied to each.

> The former is a "control" character, which has specific semantics
> associated with it; the latter is a "printable" character, which is
> usually printed and interpreted as itself (although in this particular
> case, the printed representation is hard to see on most output
> devices).

And those specific semantics make the display of those characters easily
confused. That is why it's generally a bad idea to use U+0009 in text
edited by humans.

> This mailing list doesn't seem to mind that lines beginning with ASCII
> SPC characters are semantically different from lines beginning with
> ASCII LF characters, although many detractors of Python seem unduly
> fixated on it.

The salient difference being that U+000A LINE FEED is easily visually
distinguished from a short sequence of U+0020 SPACE characters. This
avoids the confusion, and makes use of both together unproblematic.

-- 
 \       “Come on Milhouse, there’s no such thing as a soul! It’s just |
  `\      something they made up to scare kids, like the Boogie Man or |
_o__)                          Michael Jackson.” —Bart, _The Simpsons_ |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#74150

Le mardi 8 juillet 2014 03:22:25 UTC+2, Ben Finney a écrit :

> 
> 
> A group of (a particular amount of) U+0020 characters is visually
> 
> indistinguishable from a U+0009 character, when the default semantics
> 
> are applied to each.
> 
> 

Tabs and tabulations are the only way to align text
properly. There is no other way. Can be "Python",
txt, word, ..., everything.

For the promoters of "just configure your editor":
make these invsible chars visible.

[toc] | [prev] | [next] | [standalone]

#74152

On Tue, 08 Jul 2014 11:22:25 +1000, Ben Finney wrote:

> A group of (a particular amount of) U+0020 characters is visually
> indistinguishable from a U+0009 character, when the default semantics
> are applied to each.

Hmmm. I'm not sure there actually *is* such a thing as "default 
semantics" for tabs. If you look at a tab character in a font, it 
probably looks like a single space, but that depends on the font 
designer. But if you look at it in a text editor, it will probably look 
like eight spaces, unless it looks like four, or some other number, and 
if you look at it in a word processor, it will probably look like a "jump 
to the next tab stop" command. In a spreadsheet application, it will be a 
cell separator and consequently doesn't look like anything at all. I 
don't think any of those things count as "default semantics".

The point being, tabs are *control characters*, like newlines and 
carriage returns and form feeds, not regular characters like spaces and 
"A" or "λ". Since "indent" is an *instruction* rather than a character, 
it is best handled with a control character.

In any case, if we limit ourselves to text editors, only a specific 
number of spaces will be visually indistinguishable from a tab, where the 
number depends on which column you start with:

x	x	# Tab
x       x	# Seven spaces
x      x	# Six spaces
x        x	# Eight spaces


Even in a proportional font, the last two should be distinguishable from 
the first two. Admittedly, that does leave the case where N spaces (for 
some 1 <= N <= 8) looks like a tab. That's a probably, but it's not the 
only one:

* End of line is a problem. I know of *at least* the following seven 
conventions for end-of-line:

    - ASCII line feed, \n (Unix etc.)
    - ASCII carriage return, \r (Acorn, ZX Spectrum, Apple, etc.)
    - ASCII \r\n (CP/M, DOS, Windows, Symbian, Palm, etc.)
    - ASCII \n\r (RISC OS)
    - ASCII Record Separator, \x1E (QNX)
    - EBCDIC New Line, \N{NEXT LINE} in Unicode (IBM mainframes)
    - ATASCII \x9B (Atari)

* Form feeds are a problem, since they are invisible, but still get used 
(by Vim or Emacs, I forget which) to mark sections of text.

* Issues to do with word-wrapping and hyphenation, or lack thereof, are a 
problem.

* Encoding issues are a problem.

* There are other invisible characters than spaces (non-breaking space, 
em-space, en-space, thin space).


The solution is to use a smarter editor. For example, an editor might 
draw a horizontal rule to show a form feed on a line of its own, or 
highlight unexpected carriage return characters with ^M, or display tabs 
in a different colour from spaces, or overlay it with a \x09 glyph. Or an 
editor might be smart enough to automatically do what the current 
paragraph or block does: if the block is already indented with tabs, 
pressing tab inserts a tab, but if it is indented with spaces, pressing 
tab inserts spaces.

Isn't this why you recommend people use a programmer's editor rather than 
Notepad? A good editor should handle these things for you automatically, 
or at least with a minimum amount of manual effort.


>> The former is a "control" character, which has specific semantics
>> associated with it; the latter is a "printable" character, which is
>> usually printed and interpreted as itself (although in this particular
>> case, the printed representation is hard to see on most output
>> devices).
> 
> And those specific semantics make the display of those characters easily
> confused. That is why it's generally a bad idea to use U+0009 in text
> edited by humans.

I disagree. Using tabs is no more a bad idea than using a formfeed, or 
having support for multiple encodings.


>> This mailing list doesn't seem to mind that lines beginning with ASCII
>> SPC characters are semantically different from lines beginning with
>> ASCII LF characters, although many detractors of Python seem unduly
>> fixated on it.
> 
> The salient difference being that U+000A LINE FEED is easily visually
> distinguished from a short sequence of U+0020 SPACE characters. This
> avoids the confusion, and makes use of both together unproblematic.

True, but that's *only* because your editor chooses to follow the 
convention "display a LINE FEED by starting a new line" rather than by 
the convention "display the (invisible or zero-width) glyph of the LINE 
FEED". If editors were to standardise on the convention "display a 
HORIZONTAL TAB character as visibly distinct from a sequence of 
spaces" (e.g. by shading the background a different colour, or overlying 
it with an arrow) then we would not be having this discussion.

In other words, it is the choice of editors to be *insufficiently smart* 
about tabs that causes the problem. There is a vicious circle here:

* editors don't handle tabs correctly

* which leads to (some) people believing that "tabs are bad" and should 
be avoided

* which leads to editors failing to handle tabs correctly, because "tabs 
are bad" and should be avoided.


A pity really.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#74157

On Tue, Jul 8, 2014 at 6:48 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> If editors were to standardise on the convention "display a
> HORIZONTAL TAB character as visibly distinct from a sequence of
> spaces" (e.g. by shading the background a different colour, or overlying
> it with an arrow)

DeScribe Word Processor has (had? it hasn't been developed in about a
decade... but it still runs just fine) a whole lot of visual guides
for metacharacters, which can be turned on or off. Normally, we prefer
not to have a little dot to mark every 0x20 space, but you can have
'em if you want 'em; tabs get shown as diamonds; paragraph markers as
pilcrows; line breaks as a small circle; and so on. (The difference
between a paragraph and a line break isn't a normal one in most text
editors, so I'd be looking at representing U+000A newlines with a
pilcrow, probably.) Obviously you need a means of distinguishing the
end-of-line marker from an actual character, since PILCROW SIGN is a
perfectly acceptable character; but if the metacharacters are shown
in, say, a pale blue, rather than the usual black text, it'd be easy
enough.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74158

Steven D'Aprano <steve@pearwood.info>:

> * editors don't handle tabs correctly

But you said yourself:

> I'm not sure there actually *is* such a thing as "default semantics"
> for tabs.

What is "correct" handling of ASCII TAB characters in a text file?

The unix tradition is to let the TTY interpret the TABs. Utilities such
as "ed", "cat", "diff" or "gcc" don't interpret or process TABs in any
way but simply output them together with the rest of the text.

And the TTY tradition is to have TAB stops at every 8 columns (by
default).

So this question has little to do with text editors except in that your
editor should display your program roughly the same way as "lpr" prints
it out.


Marko

[toc] | [prev] | [next] | [standalone]

#74160

On Tue, Jul 8, 2014 at 7:09 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> The unix tradition is to let the TTY interpret the TABs. Utilities such
> as "ed", "cat", "diff" or "gcc" don't interpret or process TABs in any
> way but simply output them together with the rest of the text.

Not quite; tools like diff that put a character at the beginning of
the line are likely to be tab-aware, and gcc is certainly going to
comprehend them (at least to the extent of treating them as
whitespace). And I think less takes notice of them, too, so it's only
the very simplest tools like cat that actually ignore them or treat
them as single characters (or even bytes).

ChrisA

[toc] | [prev] | [next] | [standalone]

#74164

Chris Angelico <rosuav@gmail.com>:

> Not quite; tools like diff that put a character at the beginning of
> the line are likely to be tab-aware,

No, just tried it again: diff outputs tabs as tabs.

   $ diff abc def
   1,2c1,2
   <       abc
   <         abc
   ---
   >       def
   >         def

where line 1 begins with a tab and line 2 begins with 8 spaces in each
file.

> and gcc is certainly going to comprehend them

   $ gcc -c test.c
   test.c:1:2: error: expected identifier or ‘(’ at end of input

where test.c contains

   <TAB>(<LF>

IOW, gcc reports that the open parenthesis is in column 2.

> (at least to the extent of treating them as whitespace).

Sure, but that doesn't concern the tab stops in any way.

> And I think less takes notice of them, too,

How?

> so it's only the very simplest tools like cat that actually ignore
> them or treat them as single characters (or even bytes).

They all seem to be "simple." At least Python is:

   $ python3 -c 'print	('
     File "<string>", line 1
       print	(
             ^
   SyntaxError: unexpected EOF while parsing

where the caret is pointing at the wrong visual column.


Marko

[toc] | [prev] | [next] | [standalone]

#74165

On Tue, Jul 8, 2014 at 9:13 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> Not quite; tools like diff that put a character at the beginning of
>> the line are likely to be tab-aware,
>
> No, just tried it again: diff outputs tabs as tabs.
>
>    $ diff abc def
>    1,2c1,2
>    <       abc
>    <         abc
>    ---
>    >       def
>    >         def
>
> where line 1 begins with a tab and line 2 begins with 8 spaces in each
> file.

Check out its -t and -T options; diff is definitely tab-aware.

>> and gcc is certainly going to comprehend them
>
>    $ gcc -c test.c
>    test.c:1:2: error: expected identifier or ‘(’ at end of input
>
> where test.c contains
>
>    <TAB>(<LF>
>
> IOW, gcc reports that the open parenthesis is in column 2.

It's easier to number the positions that way, in the same way that you
would number lines - by how many times you have to hit down or right
arrow to get there. In my MUD client, I measure text positions in
characters (within a line; a particular position is identified by
(line, char), because lines are generally far more important than
overall positions), even when tabs are involved; a tab simply counts
as one character, even though it displays as up to eight times the
width. Actually, I'm currently contemplating a reworking of how that's
all mapped out, which would mean that *any* character is allowed to
take up *any* width, including zero, in which case the only
significance is that a tab takes up a variable width depending on
where it is in the line (which is already coped with).

>> And I think less takes notice of them, too,
>
> How?

Shrink your terminal down to some weird width like 45, create a file
with long lines including tabs, 'less' the file, and use the right
arrow key to scroll horizontally. It takes note of tabs and renders
them properly.

>> so it's only the very simplest tools like cat that actually ignore
>> them or treat them as single characters (or even bytes).
>
> They all seem to be "simple." At least Python is:
>
>    $ python3 -c 'print  ('
>      File "<string>", line 1
>        print    (
>              ^
>    SyntaxError: unexpected EOF while parsing
>
> where the caret is pointing at the wrong visual column.

If someone cares enough to write a patch, I'm sure the traceback
renderer could be improved. But how many people actually use tabs
inside code like that?

ChrisA

[toc] | [prev] | [next] | [standalone]

#74225

Steven D'Aprano <steve@pearwood.info> writes:

> On Tue, 08 Jul 2014 11:22:25 +1000, Ben Finney wrote:
>
> > A group of (a particular amount of) U+0020 characters is visually
> > indistinguishable from a U+0009 character, when the default semantics
> > are applied to each.
>
> Hmmm. I'm not sure there actually *is* such a thing as "default 
> semantics" for tabs.

It was likely never standardised, but yes, default semantics are long
established for the HT (Horizontal Tab) control code in a text stream
<URL:https://en.wikipedia.org/wiki/Tab_key#Tab_characters>.

The default semantics are that an HT (Horizontal Tabulation) control
code is an instruction to introduce enough horizontal space such that
the following character appears at the next multiple-of-8 column. These
semantics assume a fixed character width, which is itself a default
semantic of the display of computer text; variable-width is a deviation
from the default.

> If you look at a tab character in a font

I'm not talking about glyphs (for a control code, there isn't much sense
talking about a default glyph), I'm talking about the default semantics
of how they affect display.

> But if you look at it in a text editor, it will probably look like
> eight spaces, unless it looks like four, or some other number, and if
> you look at it in a word processor, it will probably look like a "jump
> to the next tab stop" command.

Right. Programs that conform to the established default semantics for an
HT (U+0009) code point will shift to the next tab stop to display the
following character. Tab stops themselves are, in fixed-width character
layout (which is itself the historical default), spaced apart by
multiples of 8 character columns.

> I don't think any of those things count as "default semantics".

I hope my position is clearer.

> The point being, tabs are *control characters*, like newlines and
> carriage returns and form feeds, not regular characters like spaces
> and "A" or "λ". Since "indent" is an *instruction* rather than a
> character, it is best handled with a control character.

Right. And those control codes affect display of the text, and there are
default semantics for those codes: what those control codes specifically
mean. The HT code has the default display semantic of “display the
following character at the next horizontal tab stop”.

> The solution is to use a smarter editor.

The recipient's choice of editor program is not within the control of
the author. Furthermore, it's expecting that the recipient will deviate
from the default display semantics of the text as received.

The author should write the text such that the default semantics are
useful, and/or avoid text where the default semantics are undesirable or
unreliably implemented.

In this case: If the programmer doesn't like U+0009 resulting in text
aligned at multiple-of-8 tab stops, or doesn't like the fact that
recipients may have tab stops set differently, then I don't care what
editor the author uses; they should avoid putting U+0009 into text.

That said, a smarter text editor program *can* be a solution for “I
don't like the default semantics *as displayed on my computer*”.

If a programmer wants to deviate from the defaults, and can convince
others on a rational and non-coercive basis to go along with their
non-default preferences, they all have my blessing.

If they want their preferences to override the default more broadly,
they need a better argument than “it just looks better to me”.

> Isn't this why you recommend people use a programmer's editor rather
> than Notepad?

I don't see how recommending a better editor for the *author* addresses
how the *recipient*'s device renders the text. so no, that's not a
reason why I recommend the author use a programmer's editor.

> True, but that's *only* because your editor chooses to follow the
> convention "display a LINE FEED by starting a new line" rather than by
> the convention "display the (invisible or zero-width) glyph of the
> LINE FEED". If editors were to standardise on the convention "display
> a HORIZONTAL TAB character as visibly distinct from a sequence of
> spaces" (e.g. by shading the background a different colour, or
> overlying it with an arrow) then we would not be having this
> discussion.

If things were different, they'd be different. I'm talking about default
display semantics of the U+0009 code as they are.

-- 
 \          “I used to be an airline pilot. I got fired because I kept |
  `\       locking the keys in the plane. They caught me on an 80 foot |
_o__)                    stepladder with a coathanger.” —Steven Wright |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#74241

I'm neutral, I do not wish to convince anybody, I'm reacting
like a normal user and on top of this I wrote interactive
intepreters (gui).

My conclusion: "tabs" everywhere: simple, practical, perfect
look and it is always working (I never meet a case, where
tab may be a problem).

Ditto with all the editors I'm using.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web