Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Tabs -vs- Spaces: Tabs should have won.

Reply
Thread Tools

Tabs -vs- Spaces: Tabs should have won.

 
 
rantingrick
Guest
Posts: n/a
 
      07-16-2011

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

 
Reply With Quote
 
 
 
 
Tim Chase
Guest
Posts: n/a
 
      07-16-2011
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




 
Reply With Quote
 
 
 
 
Andrew Berg
Guest
Posts: n/a
 
      07-16-2011
-----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+vKVyh9J38ATpe0AZmYtc44s1q6pg8 mUYrgdc77IVtrc
L/gPE/zw+R1aMcZDsAaZRU/UL0DrbrUKWAPJbPgA8Z5yXlBqR6a9/zYz8Uu96NlG
Ma9abDC77fPtj9YuiGdqpRfJoF5ed4ZnWbYXukcT6L6VjJXA/Yt0ofb84iHl3To2
h8nSVhxfc2DOzUZBrnPQlxs7rSzo2lW3JhVhS25gnke2l9/aM1TF9vUet8qmaKtN
2neGYUGWqy9j7f9/w0IP/Wp7bO0aK/a7AxrNCCMevSUSptcvHB93Ngbl3qZNAC8=
=OfNc
-----END PGP SIGNATURE-----
 
Reply With Quote
 
Cameron Simpson
Guest
Posts: n/a
 
      07-16-2011
On 16Jul2011 09:51, rantingrick <(E-Mail Removed)> 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 <(E-Mail Removed)> DoD#743
http://www.cskk.ezoshosting.com/cs/

Will you come quietly, or shall I use earplugs?
 
Reply With Quote
 
Andrew Berg
Guest
Posts: n/a
 
      07-17-2011
-----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 = '(E-Mail Removed)',
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+rPQd8EnDuawGgF tq0h+5m2oMrWTV
dG+53im/TD3t9vU8ElsQ4gdINV99bw2jASJA2zrFwUS7QWAadqHWfZji1J gJkp+k
BupqXbBWaKZn9tREDbWNeTp3byHD0WFs6ZZp5ZxRxYCMNl4I4Y MWgkSQuRmQJRy+
3FuFokUz9uyCQk/pHD9JSQqiB2mkXBLZbXU0V71rTBqGIWe+u0n+DggWAAYNAK5R
U+neKJAfwHfwNcgCI0r56gNl1fWc5cOXzT7HcPW4cErvgsBXOO GicPoxZTZZ05I=
=6w/9
-----END PGP SIGNATURE-----
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      07-17-2011
On Sun, Jul 17, 2011 at 9:52 AM, Cameron Simpson <(E-Mail Removed)> 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
 
Reply With Quote
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      07-17-2011
On Sun, 17 Jul 2011 09:52:45 +1000, Cameron Simpson <(E-Mail Removed)>
declaimed the following in gmane.comp.python.general:

> On 16Jul2011 09:51, rantingrick <(E-Mail Removed)> 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://www.velocityreviews.com/forums/(E-Mail Removed) HTTP://wlfraed.home.netcom.com/

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-17-2011
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

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-17-2011
Cameron Simpson wrote:

> On 16Jul2011 09:51, rantingrick <(E-Mail Removed)> 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

 
Reply With Quote
 
Andrew Berg
Guest
Posts: n/a
 
      07-17-2011
-----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+VF5g8pQ mPyQ6mJTXuu
8uVS5yxXyH4h5sYpONFzMdPSQdZHFUggmEfUZ3xkJ2OWwJBDtr UrIQIgs2qopIxG
Cx8sM1hg9mkcILN95e9qVkohXAzHl4R6tXSVC+vYj0k4TMM6sj 5CowzgorbfpgA=
=YvS2
-----END PGP SIGNATURE-----
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
I have tabs in ff enabled. Why won't it let me have more than R. audit2 Firefox 1 09-25-2011 03:10 AM
What the...? Hash does not have a key it really should have! Joshua Muheim Ruby 5 08-11-2007 02:17 PM
CSV::Writer... Using tabs instead of commas (or creating excel file using tabs to seperate data) John Kopanas Ruby 2 01-29-2007 06:26 PM
How should i go about creating a tabs that load different forms? axristo@gmail.com ASP .Net 1 10-25-2006 04:32 PM
List text files showing LFs and expanded tabs (was: Colorize expanded tabs) qwweeeit Python 2 12-14-2005 10:07 AM



Advertisments