Who are the "spacists"?

Chris Angelico rosuav at gmail.com
Mon Mar 20 04:15:14 EDT 2017


On Mon, Mar 20, 2017 at 6:37 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> I don't use paper, but I tried cat and Firefox. In each case, the tab
>> characters showed precisely as they should: as indentation. Was it the
>> exact same amount of indentation that showed when I originally wrote
>> the text in my editor? Was it displayed in the same font as my text
>> editor uses? Was the window the same size as that of my text editor?
>> Was the text colour the same everywhere? And do any of these questions
>> even matter?
>
> Those questions do matter when you mix whitespace and tabs, as well as
> in cases like these:
>
>     call_some_function(1,
>                        2,
>                        3)
>
> The tools I mentioned honor the traditional tab stop columns:
>
>     1, 9, 17, 25, 33, 41, 49, 57, 65, 73

(Point of clarity: "whitespace" is a general term that covers U+0020
SPACE, U+0009 CHARACTER TABULATION, U+000A LINE FEED, U+2008
PUNCTUATION SPACE, and others. You're talking about mixing *spaces*
and tabs.)

That means that you were depending, in your source file, on something
that isn't actually part of the character's definition. You're
depending on "horizontal tab" meaning those exact tab stops. If you
want those semantics, you should use spaces - or better still, *change
your needs* and don't align things like that. In far too many fonts,
this simply won't work. (It was only from context that I figured out
that that's what you were even aiming for. It didn't work in my
email.)

>> Semantically, indentation is indentation.
>
> The presence of a HT code point in a plain text file is not a semantic
> marker for indentation. It is a silly, traditional compression scheme
> for whitespace.

Only if you truly expect and assume that. Can you show me a standards
document that says "the meaning of this byte/character value is this
sequence of this other byte/character"?

>> I prefer to use tabs in my code precisely *because* they are not
>> defined in a concrete way.
>
> If you ever had to review C source code pull requests where tabs and
> spaces alternate randomly...

Yes, and if you've ever had to review source code pull requests where
the letters "q" and "e" were used interchangeably, you'd also be
appalled. The different kinds of whitespace have different semantic
meanings, and while I'm sympathetic to the desire to stick to ASCII
where possible (resulting in a pair of newlines often being used to
represent a paragraph, where semantically U+2029 PARAGRAPH SEPARATOR
would be more appropriate), I believe that the meanings of different
characters should be respected. You wouldn't separate words in a
sentence with form-feeds; nor should you mix tabulation and space
characters to create indentation.

ChrisA



More information about the Python-list mailing list