Tabs -vs- Spaces: Tabs should have won.

Discussion in 'Python' started by rantingrick, Jul 16, 2011.

  1. rantingrick

    rantingrick Guest

    --------------------------------------------------
    Summary
    --------------------------------------------------
    As we all know python allows us to use either tabs or spaces but NEVER
    both in the same source file. And as we also know the python style
    guide says we should use four spaces and refrain from using tabs at
    all costs. Up until now i have blindly followed this pronouncement
    form our leader.

    --------------------------------------------------
    Realization: A splinter in my mind
    --------------------------------------------------
    However lately i have begun to question this convention. Not only the
    idea of spaces over tabs, but also the idea of allowing both types of
    indention in a language simultaneously. The latter of which greatly
    reflects Guido's lack to remove multiplicity from this language. I
    believe he included both due more to emotion than logic.

    --------------------------------------------------
    Evidence: Tabs ARE superior!
    --------------------------------------------------
    I have begun to believe that tabs are far more superior to spaces, and
    there are many undeniable facts that support this belief that "tabs
    only" was the correct and ONLY choice:

    1) Using only one indention token removes any chance of user error.

    Unlike many syntactical errors, indention is invisible in a text/
    source editor. Sure there are tools that can make indention visible,
    however why do we constantly create asinine rules that force us to use
    complicated tools when we could have choose tabs and none of this
    would have been a problem? Another big issue with allowing two types
    (and not allowing them to be mixed) is the huge confusion that
    beginner get when they see a "inconsistent indentation" error. They
    had no idea that creating a file with notepad and then editing it with
    IDLE would case the source to blow up. We should have never had these
    problems arise because we should have never allowed spaces for
    indention.

    2) Tabs create unity in the source code base.

    When we use "tabs only" we create a code base that promotes unity and
    not conformity. There shall no longer be "inconsistent indentation
    errors" due to mixing tabs and spaces. Also we can remove multiplicity
    from the compiler. The compiler no loger has to consider BOTH tabs AND
    spaces as valid indention tokens, only tabs. The logic would be much
    simpler.

    3) Tabs create freedom in the form of user controlled indention.

    Indention width should be a choice of the reader NOT the author. We
    should never "code in" indention width; but that is EXACTLY what we
    are doing with spaces! No, the reader should be able to choose the
    indention width without ANY formatting required or without any
    collateral damage to the source code. Tabs offer freedom, spaces offer
    oppression.

    4) Tabs remove the need for complicated indention/detention tools.

    With "tabs only" you no longer need those fancy tools to indent or de-
    dent after a tab or backspace key-press. THAT IS EXACTLY WHY TABS
    WHERE INVENTED! Why are we not using this technology? Why are we
    continuing to promote spaces when tabs are obviously more superior?

    --------------------------------------------------
    Conclusion: There IS freedom in unity!
    --------------------------------------------------
    When you can create a mandate that brings both UNITY and FREEDOM to
    your community you know you made the correct choice! Tabs are both
    unity and freedom at the same time because tabs UNIFY the code base
    whist giving FREEDOM to view source in any indentation with WITHOUT
    extra formatting required.

    Source code must follow rules. And source code authors must follow
    these rule. Anyone who claims that syntactical rules in a programming
    language are evil because these rules "somehow" quell freedom is just
    a complete nut job. Programming languages MUST have rules or
    ambiguities will run a muck and bring the entire system crashing down.

    Some would argue that allowing both tabs and spaces is freedom,
    however this line of reasoning is flawed. Allowing a programmer to
    format his code in way he pleases is bad, bad, bad. As a member of a
    community we must all format our code in the same manner. We are each
    responsible for the community as a whole and as such much follow some
    rules.

    Would it be wise for folks to choose which side of the road to drive
    on?
    Would it be wise for folks to choose which red lights to stop at (or
    not stop at)?
    Would it be wise to allow people to kill other people in the name of
    freedom?

    If we continue along this flawed line of reasoning then one could
    extrapolate just about any excuse for any action under the guise of
    personal freedom. These people are selfish by nature and they don't
    care about their own responsibilities to a greater community. They
    exist only to please themselves. We (as a community) should not care
    what they think until they decide to stop being selfish.

    We should never create languages that cater to the selfish. Our rules
    must take in consideration the "good of the many", and NEVER "the good
    of the few". We should ALWAYS give our community freedoms; but only
    the freedoms that foster unity! Tabs meet both criteria and as such
    should be Pythons only token for indention formatting.
     
    rantingrick, Jul 16, 2011
    #1
    1. Advertising

  2. rantingrick

    Tim Chase Guest

    Re: feeding the troll (was: Tabs -vs- Spaces: Tabs should have won.)

    On 07/16/2011 11:51 AM, rantingrick wrote:
    > 1) Using only one indention token removes any chance of user error.


    I'm not sure it "removes any chance of user error"...programmers
    are an awfully error-prone lot -- especially beginners. Picking
    one or the other might help reduce friction when learning or
    shifting between projects (which PEP-8's 4-space guideline does),
    but editor peculiarities may differingly save files.

    > 2) Tabs create unity in the source code base.


    This could go either way...fortunately the code is already
    written and tested and appropriately handles both tabs and
    spaces. A dictum one way or the other would break existing code
    on the shunned side. I can't say this is a particularly
    convincing argument.

    > 3) Tabs create freedom in the form of user controlled indention.
    >
    > Indention width should be a choice of the reader NOT the author. We
    > should never "code in" indention width; but that is EXACTLY what we
    > are doing with spaces! No, the reader should be able to choose the
    > indention width without ANY formatting required or without any
    > collateral damage to the source code. Tabs offer freedom, spaces offer
    > oppression.


    While I prefer tabs for exactly this solitary reason, the fact
    that it means agreeing with rantingrick is almost argument enough
    to start preferring spaces. :)

    > 4) Tabs remove the need for complicated indention/detention tools.


    I'm not sure this has ever impacted me. It's always been a
    function of the editor, and using Vim, this is a non-issue for
    me. I've used several other editors as well and most worth any
    time-investment have options to control just this behavior
    (expanding tabs to spaces & how many spaces a tab should be
    treated as). I flip back and forth between several projects,
    some use PEP-8's 4-space indentations, some use a single tab, and
    one uses an oddball 2-space indentation. It's a single command
    in Vim to adjust for the projects, and the ones I work on most
    frequently are the ones I have set as my defaults.

    > We should never create languages that cater to the selfish. Our rules
    > must take in consideration the "good of the many", and NEVER "the good
    > of the few".


    so sayith the guy who selfishly wants to change existing
    standards of freedom-for-many to the preference of his few? :)

    -tkc
     
    Tim Chase, Jul 16, 2011
    #2
    1. Advertising

  3. rantingrick

    Andrew Berg Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: RIPEMD160

    On 2011.07.16 11:51 AM, rantingrick wrote:
    > -------------------------------------------------- Evidence: Tabs ARE
    > superior! --------------------------------------------------

    That may be the case (for indentation, NOT alignment), but you're still
    a damn troll. ;)


    - --
    CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iQEcBAEBAwAGBQJOIhfBAAoJEPiOA0Bgp4/LQpIH/0AlLR09VPedCQMoeyRfoRxd
    Xbimrp+am1RiW3ysln1s+vKVyh9J38ATpe0AZmYtc44s1q6pg8mUYrgdc77IVtrc
    L/gPE/zw+R1aMcZDsAaZRU/UL0DrbrUKWAPJbPgA8Z5yXlBqR6a9/zYz8Uu96NlG
    Ma9abDC77fPtj9YuiGdqpRfJoF5ed4ZnWbYXukcT6L6VjJXA/Yt0ofb84iHl3To2
    h8nSVhxfc2DOzUZBrnPQlxs7rSzo2lW3JhVhS25gnke2l9/aM1TF9vUet8qmaKtN
    2neGYUGWqy9j7f9/w0IP/Wp7bO0aK/a7AxrNCCMevSUSptcvHB93Ngbl3qZNAC8=
    =OfNc
    -----END PGP SIGNATURE-----
     
    Andrew Berg, Jul 16, 2011
    #3
  4. On 16Jul2011 09:51, rantingrick <> trolled:
    | Evidence: Tabs ARE superior!
    | --------------------------------------------------
    | I have begun to believe that tabs are far more superior to spaces

    Please Rick: you need at least three things to use the term "more
    superior". With only two, you just have superior. It grates.

    Personally, I prefer spaces to tabs, at least fgor my Python code and
    generally anyway. Why? Well to some extent because I share files with
    another who uses 4 position tabs. Editing these is a real nightmare if
    one uses 8 position tabs (as I do, the common editor/terminal default
    these days). For pure indentation you may get sane (if wider that liked)
    results, bit any multicolumn stuff is badly broken by the mismatch.

    Personally, I like to use the tab _key_ as an input device, but to have
    my editor write real spaces to the file in consequence. With pure
    spaces, the text is laid out reliably for us both. And so I have my
    editor set to that behaviour.

    [...]
    | 3) Tabs create freedom in the form of user controlled indention.

    Only for leading indentation, not following indentation.
    Consider docstrings and other stuff with embedded fixed witdh layout.

    | Indention width should be a choice of the reader NOT the author.

    Sure, perhaps.

    | 4) Tabs remove the need for complicated indention/detention tools.
    | With "tabs only" you no longer need those fancy tools to indent or de-
    | dent after a tab or backspace key-press. THAT IS EXACTLY WHY TABS
    | WHERE INVENTED! Why are we not using this technology? Why are we
    | continuing to promote spaces when tabs are obviously more superior?

    Again with the more superior:-( Tabs were devised to lay out multiple
    columns reliably on physical media, to produce tabular output. But your
    proposal really only works for leading indents in a fixed with system,
    not multiple indents on the same line (see my 4 versus 8 example
    above).

    | --------------------------------------------------
    | Conclusion: There IS freedom in unity!
    | --------------------------------------------------
    | When you can create a mandate that brings both UNITY and FREEDOM to
    | your community you know you made the correct choice! Tabs are both
    | unity and freedom at the same time because tabs UNIFY the code base
    | whist giving FREEDOM to view source in any indentation with WITHOUT
    | extra formatting required.
    |
    | Source code must follow rules. And source code authors must follow
    | these rule. Anyone who claims that syntactical rules in a programming
    | language are evil because these rules "somehow" quell freedom is just
    | a complete nut job. Programming languages MUST have rules or
    | ambiguities will run a muck and bring the entire system crashing down.

    "Amuck" is one word you know...

    Anyway, plenty of systems have abiguities, many very deliberate. It is
    _good_ design in many cases to deliberately leave various things
    unspecified - it allows flexibility in implementation. Provided enough
    is specified to meet the use case one should often stop at that point.

    | Some would argue that allowing both tabs and spaces is freedom,
    | however this line of reasoning is flawed. Allowing a programmer to
    | format his code in way he pleases is bad, bad, bad. As a member of a
    | community we must all format our code in the same manner.

    This leads me to think you're just trolling.

    In a particular grouping of shared code I will adhere to the agreed upon
    style guides (almost always). But forcing _your_ style guide on all
    Python users? You can just f- off.

    | Would it be wise for folks to choose which side of the road to drive
    | on?

    Sure. But so much of the world chose the _wrong_ side. I drive on the
    left, as do all right thinking people.

    | Would it be wise for folks to choose which red lights to stop at (or
    | not stop at)?

    They do already.

    | Would it be wise to allow people to kill other people in the name of
    | freedom?

    I thought they did this, too.

    | If we continue along this flawed line of reasoning then one could
    | extrapolate just about any excuse for any action under the guise of
    | personal freedom. These people are selfish by nature and they don't
    | care about their own responsibilities to a greater community. They
    | exist only to please themselves. We (as a community) should not care
    | what they think until they decide to stop being selfish.
    |
    | We should never create languages that cater to the selfish. Our rules
    | must take in consideration the "good of the many", and NEVER "the good
    | of the few". We should ALWAYS give our community freedoms; but only
    | the freedoms that foster unity! Tabs meet both criteria and as such
    | should be Pythons only token for indention formatting.

    It must be nice to always be right.

    In fact, I know it is, being so myself. You haven't yet reached that
    happy state.

    Cheers,
    --
    Cameron Simpson <> DoD#743
    http://www.cskk.ezoshosting.com/cs/

    Will you come quietly, or shall I use earplugs?
     
    Cameron Simpson, Jul 17, 2011
    #4
  5. rantingrick

    Andrew Berg Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: RIPEMD160

    On 2011.07.16 06:52 PM, Cameron Simpson wrote:
    > Only for leading indentation, not following indentation. Consider
    > docstrings and other stuff with embedded fixed witdh layout.

    I try to avoid aligning things unless not doing it really hurts
    readability for that reason. For example, in most of my source files, I
    use tabs to indent. Since Python won't allow a mix of tabs and spaces
    (for whitespace) on one line, I don't try to align things:

    else:
    self.x264_cmd = [
    self.x264_exe, self.avs_file,
    '--fps', self.fpsr,
    '--sar', self.sar,
    '--crf', self.crf,
    '--level', self.level,
    '--keyint', self.ki,
    '--min-keyint', self.minki,
    '--ref', self.ref,
    '--weightp', self.weightp,
    '--bframes', self.bframes,
    '--b-adapt', self.badapt,
    '--me', self.me,
    '--merange', self.merange,
    '--direct', self.direct,
    '--trellis', self.trellis,
    '--subme', self.subme,
    '--deblock', self.deblock,
    '--output', self.video_output
    ]

    But it's still very readable.

    However, when alignment really matters, such as in a module's setup.py,
    spaces are the way to go:

    from distutils.core import setup

    setup(
    name = 'Elucidation',
    version = '0.0.1-WIP',
    py_modules = ['elucidation'],
    author = 'Andrew Berg',
    author_email = '',
    url = '',
    platforms = 'Windows',
    description = 'Provides a class for storing information on
    multimedia files that are to be converted or remuxed and methods to
    convert and remux using popular tools.'
    )


    Of everything I've read on tabs vs. spaces, this is what makes the most
    sense to me:
    http://www.iovene.com/61/

    - --
    CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iQEcBAEBAwAGBQJOIizqAAoJEPiOA0Bgp4/Lz3MH/2intDlRrMNNtfnyJF384/yS
    +dDptVATyTfFYlEGYhVAc1DZHWC2574ZPlB+rPQd8EnDuawGgFtq0h+5m2oMrWTV
    dG+53im/TD3t9vU8ElsQ4gdINV99bw2jASJA2zrFwUS7QWAadqHWfZji1JgJkp+k
    BupqXbBWaKZn9tREDbWNeTp3byHD0WFs6ZZp5ZxRxYCMNl4I4YMWgkSQuRmQJRy+
    3FuFokUz9uyCQk/pHD9JSQqiB2mkXBLZbXU0V71rTBqGIWe+u0n+DggWAAYNAK5R
    U+neKJAfwHfwNcgCI0r56gNl1fWc5cOXzT7HcPW4cErvgsBXOOGicPoxZTZZ05I=
    =6w/9
    -----END PGP SIGNATURE-----
     
    Andrew Berg, Jul 17, 2011
    #5
  6. On Sun, Jul 17, 2011 at 9:52 AM, Cameron Simpson <> wrote:
    > | Programming languages MUST have rules or
    > | ambiguities will run a muck and bring the entire system crashing down.
    >
    > "Amuck" is one word you know...


    Yes, but maybe he's wanting to run a MUCK. It's quite possible; I run
    a MUD. Now, I'm not sure how ambiguities alone could run the MUCK
    without human intervention, but as we know, Rick has the solution to
    everything - it always involves other people doing work.

    > | We should never create languages that cater to the selfish. Our rules
    > | must take in consideration the "good of the many", and NEVER "the good
    > | of the few". We should ALWAYS give our community freedoms; but only
    > | the freedoms that foster unity! Tabs meet both criteria and as such
    > | should be Pythons only token for indention formatting.
    >
    > It must be nice to always be right.
    >
    > In fact, I know it is, being so myself. You haven't yet reached that
    > happy state.


    I was born here. It's a good place to be. (Wait, were we talking about
    Australia or Right?)

    ChrisA
     
    Chris Angelico, Jul 17, 2011
    #6
  7. On Sun, 17 Jul 2011 09:52:45 +1000, Cameron Simpson <>
    declaimed the following in gmane.comp.python.general:

    > On 16Jul2011 09:51, rantingrick <> trolled:
    > | a complete nut job. Programming languages MUST have rules or
    > | ambiguities will run a muck and bring the entire system crashing down.
    >
    > "Amuck" is one word you know...
    >

    Or the code took on a life of its own, and the ambiguities created a
    MUCK server in the background <G>
    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Jul 17, 2011
    #7
  8. Andrew Berg wrote:

    > I try to avoid aligning things unless not doing it really hurts
    > readability for that reason. For example, in most of my source files, I
    > use tabs to indent. Since Python won't allow a mix of tabs and spaces
    > (for whitespace) on one line, I don't try to align things:
    >
    > else:
    > self.x264_cmd = [
    > self.x264_exe, self.avs_file,
    > '--fps', self.fpsr,
    > '--sar', self.sar,

    [snip rest of code]
    > However, when alignment really matters, such as in a module's setup.py,
    > spaces are the way to go:
    >
    > from distutils.core import setup
    >
    > setup(
    > name = 'Elucidation',
    > version = '0.0.1-WIP',

    [snip]


    Hilariously, in my newsreader, the first example (allegedly unaligned) was
    lined up as straight as an arrow, while the allegedly aligned second
    example was completely jagged and all over the place :)

    The perils of proportional fonts.


    --
    Steven
     
    Steven D'Aprano, Jul 17, 2011
    #8
  9. Cameron Simpson wrote:

    > On 16Jul2011 09:51, rantingrick <> trolled:
    > | Evidence: Tabs ARE superior!
    > | --------------------------------------------------
    > | I have begun to believe that tabs are far more superior to spaces
    >
    > Please Rick: you need at least three things to use the term "more
    > superior". With only two, you just have superior. It grates.


    Really? If you just say "superior", how do you know if it's more superior or
    less superior?

    *wink*


    > Personally, I prefer spaces to tabs, at least fgor my Python code and
    > generally anyway. Why? Well to some extent because I share files with
    > another who uses 4 position tabs. Editing these is a real nightmare if
    > one uses 8 position tabs (as I do, the common editor/terminal default
    > these days).


    I can't fathom why 8 position tabs were *ever* the default, let alone why
    they are still the default.

    > For pure indentation you may get sane (if wider that liked)
    > results, bit any multicolumn stuff is badly broken by the mismatch.
    >
    > Personally, I like to use the tab _key_ as an input device, but to have
    > my editor write real spaces to the file in consequence. With pure
    > spaces, the text is laid out reliably for us both. And so I have my
    > editor set to that behaviour.


    I have reluctantly come to do the same thing. There is a plethora of broken
    tools out there that don't handle tabs well, and consequently even though
    tabs for indentation are objectively better, I use spaces because it is
    less worse than the alternative.

    Victory of worse-is-better.


    [...]
    > | Some would argue that allowing both tabs and spaces is freedom,
    > | however this line of reasoning is flawed. Allowing a programmer to
    > | format his code in way he pleases is bad, bad, bad. As a member of a
    > | community we must all format our code in the same manner.
    >
    > This leads me to think you're just trolling.


    Slow learner, huh? :)

    I'm not sure which is worse... that Rick is trolling, and we still give him
    the attention he craves, or that he honestly believes this crap.

    I suspect the later. I get the impression that he genuinely has so little
    self-awareness that he doesn't notice that for all his talk about FREEDOM,
    he's constantly trying to deny it to others by forcing them to do what he
    wants them to do.



    --
    Steven
     
    Steven D'Aprano, Jul 17, 2011
    #9
  10. rantingrick

    Andrew Berg Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: RIPEMD160

    On 2011.07.16 10:07 PM, Steven D'Aprano wrote:
    > Hilariously, in my newsreader, the first example (allegedly
    > unaligned) was lined up as straight as an arrow,

    It has consistent indentation, but the self.whatever references aren't
    aligned.

    > The perils of proportional fonts.

    Indeed. I have my MUA set up to always send plain text, so I don't think
    there's a way I can suggest a font to the recipient (like my favorite
    fixed-width font, Courier New).

    - --
    CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iQEcBAEBAwAGBQJOIlToAAoJEPiOA0Bgp4/Lb1MH/R/0RCHYSNpP2cbYG10oPEVI
    JTx+u2vnRDJzjlJ2B85mKz3BV/cIO67rV+3tX3C4J272bS5SfmET3QUzprSTLerb
    WIAKWL3zJF+VNSPuPI2HMnHepOV61Cjlom0GGf/dOTY/zaQCGdqx3gVy0RljUsV+
    xj/ywxsHbV3vbT34b1EtNaSIz+EnzZknd0mTBApNClv9Y+VF5g8pQmPyQ6mJTXuu
    8uVS5yxXyH4h5sYpONFzMdPSQdZHFUggmEfUZ3xkJ2OWwJBDtrUrIQIgs2qopIxG
    Cx8sM1hg9mkcILN95e9qVkohXAzHl4R6tXSVC+vYj0k4TMM6sj5CowzgorbfpgA=
    =YvS2
    -----END PGP SIGNATURE-----
     
    Andrew Berg, Jul 17, 2011
    #10
  11. On Sun, Jul 17, 2011 at 08:39, Steven D'Aprano
    <> wrote:
    >
    > I have reluctantly come to do the same thing. There is a plethora of broken
    > tools out there that don't handle tabs well, and consequently even though
    > tabs for indentation are objectively better, I use spaces because it is
    > less worse than the alternative.
    >
    > Victory of worse-is-better.

    Here too. I prefer the 8-space tabs for the simplicity of the input
    method. (even while deleting 1 keystroke will do)


    >
    >
    > [...]
    > > | Some would argue that allowing both tabs and spaces is freedom,
    > > | however this line of reasoning is flawed. Allowing a programmer to
    > > | format his code in way he pleases is bad, bad, bad. As a member of a
    > > | community we must all format our code in the same manner.
    > >
    > > This leads me to think you're just trolling.

    >
    > Slow learner, huh? :)
    >
    > I'm not sure which is worse... that Rick is trolling, and we still give him
    > the attention he craves, or that he honestly believes this crap.
    >
    > I suspect the later. I get the impression that he genuinely has so little
    > self-awareness that he doesn't notice that for all his talk about FREEDOM,
    > he's constantly trying to deny it to others by forcing them to do what he
    > wants them to do.

    (denying others freedom) Ha that he is. But given, i sometimes do go
    into these phases (complete and utter lack of self-awareness) i am not
    complaining...

    Despite all of that, i do believe it will be for the greater good, if
    all of us *decide* to use 8-space tabs.
     
    anand jeyahar, Jul 17, 2011
    #11
  12. On 17Jul2011 13:09, Steven D'Aprano <> wrote:
    | Cameron Simpson wrote:
    | > On 16Jul2011 09:51, rantingrick <> trolled:
    | > | Evidence: Tabs ARE superior!
    | > | --------------------------------------------------
    | > | I have begun to believe that tabs are far more superior to spaces
    | >
    | > Please Rick: you need at least three things to use the term "more
    | > superior". With only two, you just have superior. It grates.
    |
    | Really? If you just say "superior", how do you know if it's more superior or
    | less superior?

    Neither. We can learn from the sage Dumpty, who writes:

    `When I use a word,' Humpty Dumpty said in rather a scornful tone, `it
    means just what I choose it to mean -- neither more nor less.'

    | > Personally, I prefer spaces to tabs, at least fgor my Python code and
    | > generally anyway. Why? Well to some extent because I share files with
    | > another who uses 4 position tabs. Editing these is a real nightmare if
    | > one uses 8 position tabs (as I do, the common editor/terminal default
    | > these days).
    |
    | I can't fathom why 8 position tabs were *ever* the default, let alone why
    | they are still the default.

    Shrug. I imagine it's enough to be useful. An 80 column display gets 8
    tab stops (not counting the edges). Personally I find 8 a little more
    than I would like, but 6 is displeasing and 4 may be frustratingly small
    for some users. I used to indent in 3s at uni, 5 is odd, 7 is just weird
    and 2 seems almost not worth the effort. And 1 is taken.

    Today's lesson is brought to you by the number 37, the lowest arbitrary
    number.

    | > For pure indentation you may get sane (if wider that liked)
    | > results, bit any multicolumn stuff is badly broken by the mismatch.
    | >
    | > Personally, I like to use the tab _key_ as an input device, but to have
    | > my editor write real spaces to the file in consequence. With pure
    | > spaces, the text is laid out reliably for us both. And so I have my
    | > editor set to that behaviour.
    |
    | I have reluctantly come to do the same thing. There is a plethora of broken
    | tools out there that don't handle tabs well, and consequently even though
    | tabs for indentation are objectively better, I use spaces because it is
    | less worse than the alternative.
    |
    | Victory of worse-is-better.

    Yeah. Worse is at least reliable in this scheme.

    Cheers,
    --
    Cameron Simpson <> DoD#743
    http://www.cskk.ezoshosting.com/cs/

    It is time. Awaken, sleepers, for yet another herd of slow moving prey has
    swept into Peevetown, unaware of the sure fate of the fools that disturb the
    inhabitants. Shall it be a rending of flesh, and the lamentations of the
    sorely afflicted, or shall we be buried in a sea of drivel?
    - Woulffe <>
     
    Cameron Simpson, Jul 17, 2011
    #12
  13. rantingrick

    Andrew Berg Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: RIPEMD160

    On 2011.07.16 06:06 PM, Tim Roberts wrote:
    > That's not true. Python allows tabs and spaces to be used in the
    > same source file, and even in the same source line.

    You're right. TabError is only raised if the initial indentation is
    inconsistent.
    Not legal:
    def spam():
    <tab>print('Wonderful spam!\n')
    <4 spaces>print('Bloody Vikings!')

    Legal:
    def eggs():
    <tab>print(
    <tab><tab>'Blech!\n',<some spaces to align>'Whaddya mean, "blech"?\n',
    <tab><tab>'I don\'t like spam!\n',<spaces to align>'...'
    <tab><tab>)

    > I'm not saying it's wise

    Why not?

    - --
    CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iQEcBAEBAwAGBQJOIo9DAAoJEPiOA0Bgp4/LOk4IALdGAOb3RXyunzWiDBn3vNpr
    fIR7NdtFmNc1QtvxGm3RVV+wxUjVjeCv5bXuAr/RvYDWm+MRCCr+VbexV52sFAbm
    2G1g4rWQnRPGXvDMTq1bjJKcYFnJga/LHBqnM0mWTAms6o4d+Pj5ZJ5uK5CsFcx+
    oL7y3YuVrtw/hYRNqTaxhMMy3erayGt4h3sEDIaekNbaNwNFy/7M6+tFzPBNHupT
    EZAjkVewIDEgRqd+hCZfuanuS4mX6P2pup1dgAUiMAjEXRJO4xQ1JmmuCVXiccE/
    HyiPtiIsTorDGGtzkaSpBwc1RVeZEeluO+VeVt9pIGCupKnDcVty+1R1C1kmS2U=
    =QXtI
    -----END PGP SIGNATURE-----
     
    Andrew Berg, Jul 17, 2011
    #13
  14. rantingrick

    Ian Kelly Guest

    On Sat, Jul 16, 2011 at 9:09 PM, Steven D'Aprano
    <> wrote:
    >> Personally, I like to use the tab _key_ as an input device, but to have
    >> my editor write real spaces to the file in consequence. With pure
    >> spaces, the text is laid out reliably for us both. And so I have my
    >> editor set to that behaviour.

    >
    > I have reluctantly come to do the same thing. There is a plethora of broken
    > tools out there that don't handle tabs well, and consequently even though
    > tabs for indentation are objectively better, I use spaces because it is
    > less worse than the alternative.


    This. I used to think that tabs were better, for pretty much the
    reasons Rick outlined, but I've had enough problems with editors
    munging my tabs that I eventually found it simpler in practice to just
    go with the flow and use spaces.

    Of course, there is also another major problem with tabs that I have
    not seen pointed out yet, which is that it's not possible to strictly
    adhere to 80-column lines with tabs. I can write my code to 80
    columns using 4-space tabs, but if somebody later tries to edit the
    file using 8-space tabs, their lines will be too long. Rick's answer
    to this might be to just mandate that everybody uses 4-space tabs, but
    then this would pretty much defeat the purpose of using tabs in the
    first place.
     
    Ian Kelly, Jul 17, 2011
    #14
  15. * rantingrick (Sat, 16 Jul 2011 09:51:02 -0700 (PDT))
    > 3) Tabs create freedom in the form of user controlled indention.
    >
    > Indention width should be a choice of the reader NOT the author. We
    > should never "code in" indention width; but that is EXACTLY what we
    > are doing with spaces! No, the reader should be able to choose the
    > indention width without ANY formatting required or without any
    > collateral damage to the source code. Tabs offer freedom, spaces offer
    > oppression.


    Why are you so obsessed with indentation length? Indentation length is
    just /one/ of the formatting choices that the author makes for the
    reader - and probably the /least/ significant one.

    There is for instance maximum line length, the number of empty lines,
    the author's method of alignment, spaces between the equals sign and so
    on. These are all much more "dominant" in the source code and none of
    this is left for the reader's disposition.

    Compare for instance

    variable = 11
    anothervariable = 22

    def whatever (prettylong = 1,
    alsoprettylong = 22,
    anotherone = 33):
    pass

    to

    variable=11
    anothervariable=22
    def whatever (prettylong=1, alsoprettylong=22, anotherone=33):
    pass

    Thorsten
     
    Thorsten Kampe, Jul 17, 2011
    #15
  16. rantingrick

    Ian Kelly Guest

    On Sun, Jul 17, 2011 at 1:29 AM, Andrew Berg <> wrote:
    > You're right. TabError is only raised if the initial indentation is
    > inconsistent.
    > Not legal:
    > def spam():
    > <tab>print('Wonderful spam!\n')
    > <4 spaces>print('Bloody Vikings!')
    >
    > Legal:
    > def eggs():
    > <tab>print(
    > <tab><tab>'Blech!\n',<some spaces to align>'Whaddya mean, "blech"?\n',
    > <tab><tab>'I don\'t like spam!\n',<spaces to align>'...'
    > <tab><tab>)


    Even this is legal:

    def eggs()
    <tab>if spam:
    <tab><spaces>print("Spam and eggs")
    <tab>else:
    <tab><tab>print("Just eggs")

    It's only when you're inconsistent about the added indent of a single
    block that Python will complain.
     
    Ian Kelly, Jul 17, 2011
    #16
  17. rantingrick

    Andrew Berg Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: RIPEMD160

    On 2011.07.17 02:32 AM, Ian Kelly wrote:
    > Of course, there is also another major problem with tabs that I have
    > not seen pointed out yet, which is that it's not possible to
    > strictly adhere to 80-column lines with tabs. I can write my code to
    > 80 columns using 4-space tabs, but if somebody later tries to edit
    > the file using 8-space tabs, their lines will be too long.

    Setting an editor to read a tab as 8 spaces is just plain silly if your
    display is limited to 80 characters/line. Inserting 8 spaces as one
    indent is also a bit silly, but if you're going to do it, it's your
    responsibility to make sure the line is still less than 80 characters.

    - --
    CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iQEcBAEBAwAGBQJOIpSlAAoJEPiOA0Bgp4/L7JwH/3zysmIUDPyy6f4X7oKAFye0
    YcjgC5vM5gHQ4HGemGrIGBuurYffcC1XL3Cf7V5y4Rf6F+XwueLN1C4YEl8r1dtw
    r+E6pVsFM4e5keLoWb4s+IeBu0HV6GqHyXkEmj8kV8QG9dZJbWML42+AwGauXdO/
    IUne0zp1ojHbAY5lDVJnRako3hMyXuxJjpERZXXh/Qe+z9GyaQ4/AHrVFsYyWS3A
    ZE9L7y/Yv/Bba9DjYLs1sgFDGVF996yQFAnhPw52cmlahh3/1vbpV+CPQhIeVVH8
    PqObrFw9cdAMoo/kVoPRmcNBU+Xf9tlTDUS5w6bn7WjrYdnd28VesZ03uaapWx8=
    =tWjf
    -----END PGP SIGNATURE-----
     
    Andrew Berg, Jul 17, 2011
    #17
  18. * Andrew Berg (Sat, 16 Jul 2011 19:29:30 -0500)
    > Of everything I've read on tabs vs. spaces, this is what makes the
    > most sense to me:
    > http://www.iovene.com/61/


    Interesting one, especially the - from the coder's point of view -
    artificial distinction between indentation and alignment.

    What is the difference between indentation and alignment? Well,
    indentation works with tabs, alignment not.

    The author's conclusion "simply just use what ever you want for
    indenting, but use spaces for aligning" leaves only two choices for
    Python programmers: use spaces for indenting or don't align.

    Thorsten
     
    Thorsten Kampe, Jul 17, 2011
    #18
  19. rantingrick

    Dotan Cohen Guest

    On Sat, Jul 16, 2011 at 19:51, rantingrick <> wrote:
    > --------------------------------------------------
    >  Evidence: Tabs ARE superior!
    > --------------------------------------------------


    I am also a recent spaces-to-tabs convert. One of the reasons is that
    I've discovered that programing in a non-fixed width font is a real
    pleasure, but the spaces are too narrow. Tabs alleviate that.

    I'm still looking for the perfect programming font. Suggestions welcomed.

    --
    Dotan Cohen

    http://gibberish.co.il
    http://what-is-what.com
     
    Dotan Cohen, Jul 17, 2011
    #19
  20. rantingrick

    Andrew Berg Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: RIPEMD160

    On 2011.07.17 03:15 AM, Dotan Cohen wrote:
    > programing in a non-fixed width font is a real pleasure

    If you're masochistic, maybe. Do you find fixed-width fonts ugly? I
    really would like to know why anyone would use a non-fixed-width font
    for programming.
    > I'm still looking for the perfect programming font. Suggestions
    > welcomed.

    I use Courier New.

    - --
    CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iQEcBAEBAwAGBQJOIp7iAAoJEPiOA0Bgp4/LWzcH/0iHzlOF47JOnIJfPjbhhTu5
    KbrkE3mkQEwDtdNT4FUQb/aklHqvlmd4DWgxg25eXZ8PWAfQBPjnfKWHDSvWz7+2
    rt6MNXLfh/6wzAAAT2nJNl5QabeANYBEbSE3EvgnMe5LfVWR/vVl2upmTfxAaoWJ
    gH1Vp6TstAZluh8kcmii8dyrHXiubh9K84YS+FdRzLX3lz5mtGe+c20DWeeMiMxU
    NlIzfWQVzZa4avU+1GdWFXwgKJP5chf7lyrg1UKFmSeQUeR4MeOx1PP8spkQy51i
    fl4+VCCHOxL3Z5KVrM/aO0wTNwjYy+QddkGr+Hdk/QDNoqJwwYi8e2Nao/06HUY=
    =3pB7
    -----END PGP SIGNATURE-----
     
    Andrew Berg, Jul 17, 2011
    #20
    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. nospam
    Replies:
    2
    Views:
    5,201
    Joe Smith
    Jul 3, 2004
  2. Sandeep
    Replies:
    1
    Views:
    888
    Raymond DeCampo
    Jan 15, 2006
  3. Xah Lee
    Replies:
    42
    Views:
    1,381
    Oliver Wong
    May 23, 2006
  4. qwweeeit
    Replies:
    2
    Views:
    649
    qwweeeit
    Dec 14, 2005
  5. John Kopanas
    Replies:
    2
    Views:
    294
    Gregory Brown
    Jan 29, 2007
Loading...

Share This Page