TABS in the CPython C source code
Alf P. Steinbach
Pleasant surprise: while e.g. the gcc compiler is written in K&R C (1975 style
C), CPython seems to be written in almost modern C (1989 and on).
But, hey, TABS used for indenting, combined haphazardly and randomly with SPACES
used for indenting, in the same source files...
The size-8 tabs look really bad in an editor configured with tab size 4, as is
common in Windows. I'm concluding that the CPython programmers configure their
Visual Studio's to *nix convention. Or perhaps modern Visual Studio has default
tab size 8, it wouldn't surprise me (the best version was the MSVC 6.0 Developer
Studio, since then that IDE has only gone downhill being re-based on the Office
Assistant inspired "for dummies" IDE that Microsoft had for web designers).
Anyways, I would suggest converting all those tabs to spaces, as e.g. the Boost
library project does -- no tabs allowed.
That's much more platform-independent. :-)
Cheers,
- Alf
Andrej Mitrovic
So what's stopping you from doing this yourself?
Alf P. Steinbach
Depends what "this" you're referring to.
If by "this" you mean, automatically converting tabs to spaces on checking out a
newer version of a CPython source file, nothing in particular stops anyone from
doing that. But it's needless work, and it results in "false positive" changes
when checking in something. That's why e.g. Boost standardizes on spaces.
If by "this" you mean, changing the coding guidelines (if such exist) for the
CPython project, well I'm not involved, so the best I can do is to float the
idea and point to existing practice in other projects, which I've now done. :-)
Cheers & hth.,
- Alf
Neil Hodgson
> The size-8 tabs look really bad in an editor configured with tab size 4,
> as is common in Windows. I'm concluding that the CPython programmers
> configure their Visual Studio's to *nix convention.
Most of the core developers use Unix.
> Anyways, I would suggest converting all those tabs to spaces, as e.g.
> the Boost library project does -- no tabs allowed.
This would damage the usefulness of source control histories (svn
annotate) as all of the converted lines would show this recent cosmetic
change rather than the previous change which is likely to be a
substantive modification.
Neil
John Bokma
> Just trying to delve into the CPython source code.
>
> Pleasant surprise: while e.g. the gcc compiler is written in K&R C
> (1975 style C), CPython seems to be written in almost modern C (1989
> and on).
>
> But, hey, TABS used for indenting, combined haphazardly and randomly
> with SPACES used for indenting, in the same source files...
>
> The size-8 tabs look really bad in an editor configured with tab size
> 4, as is common in Windows.
Then you are either used a broken editor or a misconfigured editor. I've
used TextPad for ages, and it can be configured to hard tab 8 (might
even be the default [1]).
[1] With Perl coding I configured it to indent 4 spaces, hard tab 4
spaces and convert hard tabs to 4 spaces while saving, so no surprises.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
Benjamin Peterson
> This would damage the usefulness of source control histories (svn
> annotate) as all of the converted lines would show this recent cosmetic
> change rather than the previous change which is likely to be a
> substantive modification.
That's not completely true given svn diff -x -w.
Benjamin Peterson
> Anyways, I would suggest converting all those tabs to spaces
This has been discussed to death of Python-dev. We use spaces for all new files
and tabs for historical reasons in old files. Mixed ones should be converted one
way or the other.
Antoine Pitrou
> Neil Hodgson <nyamatongwe+thunder <at> gmail.com> writes:
>> annotate) as all of the converted lines would show this recent cosmetic
>> change rather than the previous change which is likely to be a
>> substantive modification.
>
That's even less true given we aren't ashamed to make other kinds of
cosmetic changes when desired, even though it also "damages the
usefulness of source control histories" ;-)
Nobody
> The size-8 tabs look really bad in an editor configured with tab size 4,
> as is common in Windows. I'm concluding that the CPython programmers
> configure their Visual Studio's to *nix convention.
8-column tabs aren't a "*nix convention"; that's been the norm since
the mechanical typewriter.
Historically, software and hardware which knows what a "tab" could be
split into two categories:
1. Tab stops are fixed at 8-column intervals.
2. Tab stops default to 8-column intervals but can be changed.
Recently, a third category has appeared (tab stops default to something
other than 8 columns). The most common example is Visual Studio. No
surprise there: Microsoft has a track record of introducing slight
incompatibilities into established standards. Just enough to inconvenience
anyone using competing products, but not so much that anyone operating
in a context where Microsoft isn't dominant has to abandon Microsoft's
product.
Given that:
1. 8-column tabs have been the standard for longer than most of us
have been alive, let alone programming, and
2. even if a particular text editor supports some other value, there is no
way to communicate this fact to anything else which might read the code,
the logical conclusion is that using anything other than 8 columns lies
somewhere between "silly" and "assuming the world revolves around you".
Alf P. Steinbach
> On Sat, 06 Feb 2010 21:31:52 +0100, Alf P. Steinbach wrote:
>
>> The size-8 tabs look really bad in an editor configured with tab size 4,
>> as is common in Windows. I'm concluding that the CPython programmers
>> configure their Visual Studio's to *nix convention.
>
> 8-column tabs aren't a "*nix convention"; that's been the norm since
> the mechanical typewriter.
>
> Historically, software and hardware which knows what a "tab" could be
> split into two categories:
>
> 1. Tab stops are fixed at 8-column intervals.
> 2. Tab stops default to 8-column intervals but can be changed.
>
> Recently, a third category has appeared (tab stops default to something
> other than 8 columns).
I'm sorry, but you have your history wrong.
Tab stops originated with mechanical typewriters, and then printers. They could
be just about anything.
Tab stops have never been universally 8 columns -- so unless by "recent"
introduction of other sizes you mean 1958 or thereabouts, you're completely off
track.
> The most common example is Visual Studio. No
> surprise there: Microsoft has a track record of introducing slight
> incompatibilities into established standards. Just enough to inconvenience
> anyone using competing products, but not so much that anyone operating
> in a context where Microsoft isn't dominant has to abandon Microsoft's
> product.
>
> Given that:
>
> 1. 8-column tabs have been the standard for longer than most of us
> have been alive, let alone programming, and
I'm sorry, that's incorrect, it's never been standard.
> 2. even if a particular text editor supports some other value, there is no
> way to communicate this fact to anything else which might read the code,
If you add the word "portable" and remove the word "other" and replace
"supports" with "is configured to use" then that's sort of technically correct.
But I agree with the general sense. And I think most everyone does. A common
convention would have been nice. But we don't have that.
> the logical conclusion is that using anything other than 8 columns lies
> somewhere between "silly" and "assuming the world revolves around you".
«the logical conclusion is that assuming 8 column tab stops lies somewhere
between "silly" and "assuming the world revolves around you"» :-)
In particular, consider Windows programming.
Aahz
Neil Hodgson <nyamatong...@gmail.com> wrote:
>Alf P. Steinbach:
>>
>> Anyways, I would suggest converting all those tabs to spaces, as e.g.
>> the Boost library project does -- no tabs allowed.
>
> This would damage the usefulness of source control histories (svn
>annotate) as all of the converted lines would show this recent cosmetic
>change rather than the previous change which is likely to be a
>substantive modification.
BTW, in case anyone is confused, it's "svn blame" vs "cvs annotate".
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
import antigravity
Steve Holden
> On Sat, 06 Feb 2010 21:31:52 +0100, Alf P. Steinbach wrote:
>
>> The size-8 tabs look really bad in an editor configured with tab size 4,
>> as is common in Windows. I'm concluding that the CPython programmers
>> configure their Visual Studio's to *nix convention.
>
> 8-column tabs aren't a "*nix convention"; that's been the norm since
> the mechanical typewriter.
>
The original mechanisms had "tab set" and "tab clear" keys, so you had
variable tabbing according to the needs of the particular document you
were working on. Look under "T" in
http://www.mytypewriter.com/explorelearn/glossary.html
if you aren't old enough to have used one.
> Historically, software and hardware which knows what a "tab" could be
> split into two categories:
>
> 1. Tab stops are fixed at 8-column intervals.
> 2. Tab stops default to 8-column intervals but can be changed.
>
> Recently, a third category has appeared (tab stops default to something
> other than 8 columns). The most common example is Visual Studio. No
> surprise there: Microsoft has a track record of introducing slight
> incompatibilities into established standards. Just enough to inconvenience
> anyone using competing products, but not so much that anyone operating
> in a context where Microsoft isn't dominant has to abandon Microsoft's
> product.
>
Consider instead that perhaps this one time Microsoft did it for the
convenience of the user (there has to be some reason why it's such a
wealthy company).
> Given that:
>
> 1. 8-column tabs have been the standard for longer than most of us
> have been alive, let alone programming, and
> 2. even if a particular text editor supports some other value, there is no
> way to communicate this fact to anything else which might read the code,
>
> the logical conclusion is that using anything other than 8 columns lies
> somewhere between "silly" and "assuming the world revolves around you".
>
Which is what you appear to be doing with your fantasy about mechanical
typewriters.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/
Steve Holden
> On Sun, 07 Feb 2010 05:49:28 +0000, Nobody <nob...@nowhere.com>
> declaimed the following in gmane.comp.python.general:
>
>
>> 8-column tabs aren't a "*nix convention"; that's been the norm since
>> the mechanical typewriter.
>>
> typewriters I learned on had any knowledge of default tab stops. All had
> a row of sliding "pins" on the carriage, which were slid back and forth
> by the <tab set> and <tab clear> button (which required one to first
> position the carriage at the position at which the stop was to be
> placed). The <tab> key itself functioned by first pushing a lever into
> the area covered by the stop-row (after the current position stop, if
> one existed), then releasing the carriage to slide until the next stop
> -- uhm -- stopped the motion by impacting the lever; releasing the <tab>
> key would then re-engage the normal carriage motion control, and
> withdraw the lever.
>
> 8-space tab stops were, I believe, the default for various computer
> terminals, DECwriter printers, and maybe teletype units (in which there
> was no moving carriage on which a physical stop could be placed). Not
> sure how an 029 keypunch machine would behave -- either punching the
> code the a tab character, or skipping to the next field defined on a
> drum-card.
>
When I started my computing career the main input medium at the
installation I worked was paper tape, and the Flexowriter (pretty much a
mechanical typewriter mechanism with a tape reader and punch attached)
was the data preparation device (though teletypes were used at other
installations). So it had adjustable tab settings.
The 029 punch (and the 026 before it) used a punch card mounte on a drum
to set the tab stops, which were therefore completely variable - one
would use a different tab card for Fortran and PL/1, for example. So a
tab was purely a spacing operation, no chads were punched from the card,
and indeed I was never aware of an EBCDIC "tab" character code (which is
by no means to say that there isn't one - Wikipedia says "The EBCDIC
code for HT is 5").
Steve Holden
> On Sun, 07 Feb 2010 05:49:28 +0000, Nobody <nob...@nowhere.com>
> declaimed the following in gmane.comp.python.general:
>
>
>> the mechanical typewriter.
>>
Terry Reedy
> Clearly written by someone who has never *used* a mechanical typewriter.
> The original mechanisms had "tab set" and "tab clear" keys, so you had
> variable tabbing according to the needs of the particular document you
> were working on. Look under "T" in
>
> http://www.mytypewriter.com/explorelearn/glossary.html
>
> if you aren't old enough to have used one.
I did start with real typewriters. The 'standard', if anything, was 1/2"
for paragraph indents. That was 5 chars with normal 10 cpi type, 6 with
12 cpi 'elite' type. I used both. I always thought the 8 char unix
indent to be excessive. If a power of 2 was needed, rounding 5 down to 4
would have been more sensible.
Wordperfect, which I wrote a couple of books with, followed the
typewriter model in defaulting tab stops to every 1/2 inch, regardless
of font. Sensible software tab defaults were not pioneered by Microsoft.
Terry Jan Reedy
Neil Hodgson
> BTW, in case anyone is confused, it's "svn blame" vs "cvs annotate".
Possibly earlier versions of SVN only supported "blame" but the
variants "annotate", "ann", and "praise" all work with the version of
SVN (1.6.5) I have installed.
Neil
Nobody
>> The size-8 tabs look really bad in an editor configured with tab size 4,
>> as is common in Windows. I'm concluding that the CPython programmers
>> configure their Visual Studio's to *nix convention.
>
> 8-column tabs aren't a "*nix convention"; that's been the norm since
> the mechanical typewriter.
Okay, as everyone has pointed out, it's not quite that old. I've seen
typewriters with fixed tabs, but I'm not certain that they were at 8
columns, and even if they were, it wasn't common enough to be a standard.