TABS in the CPython C source code

Discussion in 'Python' started by Alf P. Steinbach, Feb 6, 2010.

  1. 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. 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
     
    Alf P. Steinbach, Feb 6, 2010
    #1
    1. Advertising

  2. On Feb 6, 9:31 pm, "Alf P. Steinbach" <> wrote:
    > 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. 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


    So what's stopping you from doing this yourself?
     
    Andrej Mitrovic, Feb 6, 2010
    #2
    1. Advertising

  3. * Andrej Mitrovic:
    > On Feb 6, 9:31 pm, "Alf P. Steinbach" <> wrote:
    >> 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. 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

    >
    > So what's stopping you from doing this yourself?


    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
     
    Alf P. Steinbach, Feb 6, 2010
    #3
  4. Alf P. Steinbach

    Neil Hodgson Guest

    Alf P. Steinbach:

    > 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
     
    Neil Hodgson, Feb 6, 2010
    #4
  5. Alf P. Steinbach

    John Bokma Guest

    "Alf P. Steinbach" <> writes:

    > 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
     
    John Bokma, Feb 6, 2010
    #5
  6. Neil Hodgson <nyamatongwe+thunder <at> gmail.com> writes:
    > 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, Feb 6, 2010
    #6
  7. Alf P. Steinbach <alfps <at> start.no> writes:

    > 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.

    >
    > That's much more platform-independent.
     
    Benjamin Peterson, Feb 6, 2010
    #7
  8. Le Sat, 06 Feb 2010 22:26:55 +0000, Benjamin Peterson a écrit :
    > Neil Hodgson <nyamatongwe+thunder <at> gmail.com> writes:
    >> 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.


    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" ;-)
     
    Antoine Pitrou, Feb 6, 2010
    #8
  9. Alf P. Steinbach

    Nobody Guest

    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). 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".
     
    Nobody, Feb 7, 2010
    #9
  10. * Nobody:
    > 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.


    Cheers & hth.,

    - Alf
     
    Alf P. Steinbach, Feb 7, 2010
    #10
  11. Alf P. Steinbach

    Aahz Guest

    In article <q1lbn.5995$>,
    Neil Hodgson <> 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 () <*> http://www.pythoncraft.com/

    import antigravity
     
    Aahz, Feb 7, 2010
    #11
  12. On Sun, 07 Feb 2010 05:49:28 +0000, Nobody <>
    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.
    >

    Really? None of the various Royal, Remington, and Olivetti (sp?)
    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.

    --
    Wulfraed Dennis Lee Bieber KD6MOG
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Feb 7, 2010
    #12
  13. Alf P. Steinbach

    Steve Holden Guest

    Nobody wrote:
    > 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.
    >

    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.

    > 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, Feb 7, 2010
    #13
  14. Alf P. Steinbach

    Steve Holden Guest

    Dennis Lee Bieber wrote:
    > On Sun, 07 Feb 2010 05:49:28 +0000, Nobody <>
    > 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.
    >>

    > Really? None of the various Royal, Remington, and Olivetti (sp?)
    > 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").

    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, Feb 7, 2010
    #14
  15. Alf P. Steinbach

    Steve Holden Guest

    Dennis Lee Bieber wrote:
    > On Sun, 07 Feb 2010 05:49:28 +0000, Nobody <>
    > 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.
    >>

    > Really? None of the various Royal, Remington, and Olivetti (sp?)
    > 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").

    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, Feb 7, 2010
    #15
  16. Alf P. Steinbach

    Terry Reedy Guest

    On 2/7/2010 7:39 AM, Steve Holden wrote:

    > 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
     
    Terry Reedy, Feb 7, 2010
    #16
  17. Alf P. Steinbach

    Neil Hodgson Guest

    Aahz:

    > 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
     
    Neil Hodgson, Feb 7, 2010
    #17
  18. Alf P. Steinbach

    Nobody Guest

    On Sun, 07 Feb 2010 05:49:28 +0000, Nobody 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.


    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.
     
    Nobody, Feb 7, 2010
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xah Lee
    Replies:
    42
    Views:
    1,383
    Oliver Wong
    May 23, 2006
  2. qwweeeit
    Replies:
    2
    Views:
    651
    qwweeeit
    Dec 14, 2005
  3. Xah Lee

    Tabs versus Spaces in Source Code

    Xah Lee, May 15, 2006, in forum: Python
    Replies:
    135
    Views:
    3,690
    Oliver Wong
    May 23, 2006
  4. rantingrick

    Tabs -vs- Spaces: Tabs should have won.

    rantingrick, Jul 16, 2011, in forum: Python
    Replies:
    95
    Views:
    1,848
    Roy Smith
    Jul 19, 2011
  5. John Kopanas
    Replies:
    2
    Views:
    295
    Gregory Brown
    Jan 29, 2007
Loading...

Share This Page