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

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

Tabs -vs- Spaces: Tabs should have won.

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

Contents

  Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-16 09:51 -0700
    Re: feeding the troll (was: Tabs -vs- Spaces: Tabs should have won.) Tim Chase <python.list@tim.thechases.com> - 2011-07-16 12:52 -0500
    Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-16 17:59 -0500
    Re: Tabs -vs- Spaces: Tabs should have won. Tim Roberts <timr@probo.com> - 2011-07-16 16:06 -0700
      Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 02:29 -0500
        Re: Tabs -vs- Spaces: Tabs should have won. Tim Roberts <timr@probo.com> - 2011-07-18 22:36 -0700
      Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 01:39 -0600
    Re: Tabs -vs- Spaces: Tabs should have won. Cameron Simpson <cs@zip.com.au> - 2011-07-17 09:52 +1000
      Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-17 13:09 +1000
        Re: Tabs -vs- Spaces: Tabs should have won. anand jeyahar <anand.ibmgsi@gmail.com> - 2011-07-17 09:29 +0530
        Re: Tabs -vs- Spaces: Tabs should have won. Cameron Simpson <cs@zip.com.au> - 2011-07-17 14:12 +1000
        Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 01:32 -0600
          Re: Tabs -vs- Spaces: Tabs should have won. TheSaint <no@nowhere.net.no> - 2011-07-17 21:12 +0800
          Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 08:15 -0700
            Re: Tabs -vs- Spaces: Tabs should have won. Tim Chase <python.list@tim.thechases.com> - 2011-07-17 13:22 -0500
              Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 12:49 -0700
            Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 12:48 -0600
              Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 12:54 -0700
                Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 16:02 -0600
                  Re: Tabs -vs- Spaces: Tabs should have won. Roy Smith <roy@panix.com> - 2011-07-17 19:29 -0400
                    Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 18:55 -0500
                      Re: Tabs -vs- Spaces: Tabs should have won. Roy Smith <roy@panix.com> - 2011-07-17 20:28 -0400
                        Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 19:48 -0500
                        Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 19:50 -0500
                          Re: Tabs -vs- Spaces: Tabs should have won. Mel <mwilson@the-wire.com> - 2011-07-17 21:06 -0400
                          Re: Tabs -vs- Spaces: Tabs should have won. Mel <mwilson@the-wire.com> - 2011-07-17 21:06 -0400
                    Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-18 11:01 +1000
                      Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-18 11:12 +1000
                        Re: Tabs -vs- Spaces: Tabs should have won. Ben Finney <ben+python@benfinney.id.au> - 2011-07-18 11:42 +1000
                        Re: Tabs -vs- Spaces: Tabs should have won. Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-18 18:26 +1200
                      Re: Tabs -vs- Spaces: Tabs should have won. Tim Chase <python.list@tim.thechases.com> - 2011-07-18 05:52 -0500
                        Re: Tabs -vs- Spaces: Tabs should have won. Duncan Booth <duncan.booth@invalid.invalid> - 2011-07-18 13:52 +0000
                          Re: Tabs -vs- Spaces: Tabs should have won. MRAB <python@mrabarnett.plus.com> - 2011-07-18 17:59 +0100
                          Re: Tabs -vs- Spaces: Tabs should have won. Roy Smith <roy@panix.com> - 2011-07-18 19:07 -0400
                        Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-19 00:59 +1000
                          Re: Tabs -vs- Spaces: Tabs should have won. Dave Angel <davea@ieee.org> - 2011-07-18 13:11 -0400
                      Re: Tabs -vs- Spaces: Tabs should have won. python@bdurham.com - 2011-07-18 08:33 -0400
                      Re: Tabs -vs- Spaces: Tabs should have won. gene heskett <gheskett@wdtv.com> - 2011-07-18 10:12 -0400
                    Re: Tabs -vs- Spaces: Tabs should have won. tinnews@isbd.co.uk - 2011-07-18 10:49 +0100
                    Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-18 21:51 +0300
                    Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-18 14:06 -0500
                    Re: Tabs -vs- Spaces: Tabs should have won. Chris Angelico <rosuav@gmail.com> - 2011-07-19 05:15 +1000
        Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 02:52 -0500
        Re: Tabs -vs- Spaces: Tabs should have won. "Anders J. Munch" <2011@jmunch.dk> - 2011-07-17 11:49 +0200
          Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 09:53 -0700
            Re: Tabs -vs- Spaces: Tabs should have won. Chris Angelico <rosuav@gmail.com> - 2011-07-18 03:11 +1000
              Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 10:57 -0700
                Re: Tabs -vs- Spaces: Tabs should have won. Chris Angelico <rosuav@gmail.com> - 2011-07-18 04:09 +1000
                Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 20:20 +0200
                  Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 12:22 -0700
                  Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 22:38 +0300
                Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 22:36 +0300
              Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-18 10:54 +1000
                Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 20:26 -0500
                Re: Tabs -vs- Spaces: Tabs should have won. Teemu Likonen <tlikonen@iki.fi> - 2011-07-18 09:00 +0300
            Re: Tabs -vs- Spaces: Tabs should have won. Cameron Simpson <cs@zip.com.au> - 2011-07-18 08:14 +1000
          Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-17 21:44 +0200
            Re: Tabs -vs- Spaces: Tabs should have won. "Anders J. Munch" <2011@jmunch.dk> - 2011-07-18 20:19 +0200
          Re: Tabs -vs- Spaces: Tabs should have won. Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-18 10:06 +1200
            Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-18 18:58 +0200
    Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-16 19:29 -0500
      Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-17 13:07 +1000
        Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-16 22:20 -0500
      Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 09:56 +0200
        Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 03:36 -0500
          Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 11:33 +0200
            Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 05:02 -0500
              Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 12:42 +0200
                Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-17 14:35 +0200
                  Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 17:03 +0200
                    Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-17 21:10 +0200
                Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 09:46 -0700
                  Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 18:21 -0500
    Re: Tabs -vs- Spaces: Tabs should have won. Chris Angelico <rosuav@gmail.com> - 2011-07-17 10:31 +1000
    Re: Tabs -vs- Spaces: Tabs should have won. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-07-16 19:27 -0700
    Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 09:35 +0200
      Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 09:29 -0700
        Re: Tabs -vs- Spaces: Tabs should have won. Chris Angelico <rosuav@gmail.com> - 2011-07-18 02:50 +1000
        Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 12:54 -0600
          Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 13:12 -0700
            Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 16:39 -0600
            Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 18:18 -0500
    Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 11:15 +0300
      Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-17 14:53 +0200
        Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 22:26 +0300
          Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-17 21:53 +0200
            Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 23:46 +0300
    Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 03:35 -0500
    Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 14:11 +0300
      Re: Tabs -vs- Spaces: Tabs should have won. rusi <rustompmody@gmail.com> - 2011-07-17 04:21 -0700
      Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 13:51 +0200
        Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 22:20 +0300
          Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 21:34 +0200
            Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 13:22 -0700
    Re: Tabs -vs- Spaces: Tabs should have won. gene heskett <gheskett@wdtv.com> - 2011-07-17 10:29 -0400
      Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 17:10 +0200
        Re: Tabs -vs- Spaces: Tabs should have won. Corey Richardson <kb1pkl@aim.com> - 2011-07-17 12:28 -0400
        Re: Tabs -vs- Spaces: Tabs should have won. Anssi Saari <as@sci.fi> - 2011-07-18 19:28 +0300
          Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-18 18:51 +0200
          Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-18 19:07 +0200
      Re: Tabs -vs- Spaces: Tabs should have won. "Waldek M." <wm@localhost.localdomain> - 2011-07-17 21:39 +0200
    Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 22:28 +0300
    Re: Tabs -vs- Spaces: Tabs should have won. gene heskett <gheskett@wdtv.com> - 2011-07-17 20:35 -0400

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#9630 — Tabs -vs- Spaces: Tabs should have won.

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

[toc] | [next] | [standalone]

#9637 — 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

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

#9651

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

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

#9653

rantingrick <rantingrick@gmail.com> wrote:
>
>As we all know python allows us to use either tabs or spaces but NEVER
>both in the same source file.

That's not true.  Python allows tabs and spaces to be used in the same
source file, and even in the same source line.

I'm not saying it's wise, but it certainly allowed.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

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

#9675

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

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

#9855

Andrew Berg <bahamutzero8825@gmail.com> wrote:
>
>> I'm not saying it's wise
>
>Why not?

It just makes it more difficult to follow the pattern when you add new
code.  If you have an editor mnaging that for you, then you might as well
have the editor go all tabs or all spaces to avoid trouble.

Vi and friends with ts=8 and sw=4 will use 4 spaces, then tab, then tab
plus 4 spaces, then two tabs, etc.  That's recognizable, but I still
convert such a file to all spaces when I find one.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

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

#9679

On Sun, Jul 17, 2011 at 1:29 AM, Andrew Berg <bahamutzero8825@gmail.com> 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.

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

#9661

On 16Jul2011 09:51, rantingrick <rantingrick@gmail.com> 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 <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Will you come quietly, or shall I use earplugs?

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

#9670

Cameron Simpson wrote:

> On 16Jul2011 09:51, rantingrick <rantingrick@gmail.com> 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

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

#9673

On Sun, Jul 17, 2011 at 08:39, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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.

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

#9674

On 17Jul2011 13:09, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
| Cameron Simpson wrote:
| > On 16Jul2011 09:51, rantingrick <rantingrick@gmail.com> 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 <cs@zip.com.au> 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 <shampton@muddcs.claremont.edu>

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

#9677

On Sat, Jul 16, 2011 at 9:09 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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.

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

#9702

Ian Kelly wrote:

> but if somebody later tries to edit the
> file using 8-space tabs

I came across this and I like to put a note on top of the script
to remember to modify it accordingly.

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

#9710

On Jul 17, 2:32 am, Ian Kelly <ian.g.ke...@gmail.com> wrote:

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

Solution: STOP USING BROKEN TOOLS!!!

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

Of course it is. The litmus test will be "four-space-tab-view". If the
code overflows in this "view type" then the code will fail the 80 char
maximum limit. This argument is ridiculous anyhow. It is up to you how
to view the source. If you view it in 80 width tabs don't start
complaining later when one indention goes off the page. Would you view
the source with 50 point font? Jeez.

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

THEIR LINES is the key words. A tab control is a tab control is a (you
guessed it!) a tab control. No matter how small or large your tab
settings are the source only reflects one tab control char per press
of the tab key. Heck, people are already (unwisely) using "8-space-
spaces" and i don't hear you making the same argument.

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

We already mandate four space spaces so what is the difference? I'll
tell you, the difference is Freedom and Unity living in perfect
harmony.

Yes, we mandate that all code must meet the 80 line limit in "four-
space-tab-view", and if it doesn't, it's not allowed in the stdlib.
Plain and simple.

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

#9728

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

On 07/17/2011 10:15 AM, rantingrick wrote:
> On Jul 17, 2:32 am, Ian Kelly<ian.g.ke...@gmail.com>  wrote:
>> 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.
>
> Solution: STOP USING BROKEN TOOLS!!!

Unbroken tools that do anything worthwhile are usually 
complicated tools.

Just pointing that out in case you missed the irony...

-tkc

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

#9743

On Jul 17, 1:22 pm, Tim Chase <python.l...@tim.thechases.com> wrote:

> > Solution: STOP USING BROKEN TOOLS!!!
>
> Unbroken tools that do anything worthwhile are usually
> complicated tools.
>
> Just pointing that out in case you missed the irony...

You make a good point, albeit a very well know point. It's the same
kind of point Newton made when he wrote the laws of physics. Everyone
since cavemen knew that a falling apple would continue to fall until
the ground stopped it from falling. They just did not have the
eloquent phrasing of Newton to express the idea in words.

You've made the exact same well know expression as Newton. However we
do need to explore this subject of "broken tools vs unbroken tools" a
bit more. First let's start by understanding the difference between
broken and unbroken editors in the arena of tab width.

------------------------
 Tabs Explained:
------------------------
But what IS tab width exactly? Is it a simple unit of measurement like
four inches or 22 millimeters, or etc? Well it can be, but for the
most part it is something more. Especially in the arena of source code
editors!

In any plain text editor (i am not speaking of rich text editors or a
plain text editor in rich-text mode) where you have only one global
font choice at any given time a tab width should be the sum of N
glyphs multiplied by the current glyph width.

Here is some python code:

|>>> glyphW = 10.0 # in milimeters
|>>> def set_tab_width(nSpaces):
|	return glyphW * nSpaces
|>>> set_tab_width(1)
|10.0
|>>> set_tab_width(10)
|100.0

We as humans use "numbers of spaces" to define a tab width but
"numbers of spaces" is only an abstraction so we don't have to deal
with absolute measurements.

------------------------
 Fixed Width Fonts:
------------------------
If you are using a fixed-width-font you want the editor to use
relative spacing (relative to a glyph width) when defining tab width
in "spaces".

------------------------
 Non Fixed Width Fonts:
------------------------
On the other hand if you use non-fixed-width-font you want the editor
to use absolute measurements (since glyphs can be different widths)
when defining tab width.

------------------------
 Conclusion
------------------------
If your editor does not support as minimum the fixed width version, it
is broken. There is NOTHING complicated about creating tab width based
on the sum of N glyphs.

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

#9729

On Sun, Jul 17, 2011 at 9:15 AM, rantingrick <rantingrick@gmail.com> wrote:
>>  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.
>
> THEIR LINES is the key words. A tab control is a tab control is a (you
> guessed it!) a tab control. No matter how small or large your tab
> settings are the source only reflects one tab control char per press
> of the tab key. Heck, people are already (unwisely) using "8-space-
> spaces" and i don't hear you making the same argument.

Because the problem does not apply.  If I use 4 spaces, and somebody
else opens my file who uses 8, the code will still be limited to 80
columns.  They will just have to see my ugly 4-space indentation
instead of their preferred 8-space indentation.  You know what?  They
can cope.

>> 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.
>
> We already mandate four space spaces so what is the difference? I'll
> tell you, the difference is Freedom and Unity living in perfect
> harmony.

Let me get this straight.  You want us to use tabs so that individuals
can set their tab width to however many spaces they want, but then you
want everybody to set their tab widths to 4 spaces.  You're
contradicting yourself here.

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

#9745

On Jul 17, 1:48 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:

> Let me get this straight.  You want us to use tabs so that individuals
> can set their tab width to however many spaces they want, but then you
> want everybody to set their tab widths to 4 spaces.  You're
> contradicting yourself here.

In my mind people are free to use whatever width they like. A tab is a
tab is a tab. However for judging line widths we must pick one size
tab (since 8 space tabs will create longer lines than four space tabs.
This four space mandate is ONLY for determining line width. Let me
repeat. ONLY FOR DETERMINING LINE WIDTH.

How else could we decide what is truly 80 chars and what is not?

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

#9753

On Sun, Jul 17, 2011 at 1:54 PM, rantingrick <rantingrick@gmail.com> wrote:
> On Jul 17, 1:48 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
>
>> Let me get this straight.  You want us to use tabs so that individuals
>> can set their tab width to however many spaces they want, but then you
>> want everybody to set their tab widths to 4 spaces.  You're
>> contradicting yourself here.
>
> In my mind people are free to use whatever width they like. A tab is a
> tab is a tab. However for judging line widths we must pick one size
> tab (since 8 space tabs will create longer lines than four space tabs.
> This four space mandate is ONLY for determining line width. Let me
> repeat. ONLY FOR DETERMINING LINE WIDTH.
>
> How else could we decide what is truly 80 chars and what is not?

You're so focused on declaring code as compliant or not that you're
missing the whole point of having the line width mandate in the first
place.  It exists so that people using 80-column editors can open up
code without having line-wrapping problems.  You can arbitrarily
declare that line width is to be measured using 4-space tabs, and you
can stamp code as being correctly formatted by that metric all you
want, but it doesn't change the fact that if somebody with 8-space
tabs opens up a file and has to deal with line-wrapping problems, the
system has failed them.

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

#9761

In article <mailman.1190.1310940173.1164.python-list@python.org>,
 Ian Kelly <ian.g.kelly@gmail.com> wrote:

> the line width mandate [...] exists so that people using 80-column editors can open up
> code without having line-wrapping problems.

Heh.  I don't know how many other people on this group grew up with the 
original(*) 80-column editor (http://tinyurl.com/3sj4mzb), but I did.  
Unlike, well, any editor anybody is likely to use today, it was really, 
really hard to make the window wider if you had to.

We don't have that problem any more.  It truly boggles my mind that 
we're still churning out people with 80 column minds.  I'm willing to 
entertain arguments about readability of long lines, but the idea that 
there's something magic about 80 columns is hogwash.

* Well, not really the original.  The 026 was essentially obsolete by 
the time I came around, but the 029 was pretty much just an 026 with a 
case mod and a nicer keyboard.

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

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

csiph-web