Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

[a whole lot of guff]

Rick, you need to:

1) Grab the Python source code
2) Make your own version of Python that works the way you want it
3) Call it something different
4) Start your own mailing list.

It's funny you mention this because i am creating a specification for
a Python 4000 fork that removes all ambiguities and multiplicity from
the language. Very soon i will be posting the spec for review within
this group. Maybe some of you will come to your senses and start
implementing these important features in CPython. If not, i am not
going to waste my time forever trying to convince idiots that the
world is in fact round.

Python as it stands now will be defunct unless we make some serious
changes starting with formatting. We cannot continue to create code
bases that are so haphazardly written just for the sake of personal
freedom. Since people will not self-police we must create a mandate
that forces compliance to a style guide. Years have passed since the
first program was written. It is high time to set the standards for
formatting.

Such a system of rigorous formatting rules requires much less
interpreter logic. Python will be leaner and meaner. There won't be
any more arguing about how to format code. There will only be one way;
the correct way! Choose to follow it or die of exceptions; your
choice.

I am looking to the future and leaving the past where it belongs.
After i get a format style nailed down i will start culling the other
language specific multiplicities. Then it will be time to look outside
of Python and see what is the future of high level programming
languages.

You can choose to join me or choose to rot of old age in the self-
induced hell of antiquity. The past is bickering over selfish personal
freedoms, the future of is unity.

 

[Chris Angelico]

It's funny you mention this because i am creating a specification for
a Python 4000 fork that removes all ambiguities and multiplicity from
the language. Very soon i will be posting the spec for review within
this group. Maybe some of you will come to your senses and start
implementing these important features in CPython. If not, i am not
going to waste my time forever trying to convince idiots that the
world is in fact round.

Oh, I totally agree. And mailman is open source software so you can
even host the new Python-4000 mailing list yourself! Gather unto
thyself thy followers, and begin anew the creation of the world.

Chris Angelico

 

[Thorsten Kampe]

* rantingrick (Sun, 17 Jul 2011 10:57:10 -0700 (PDT))

Choose to follow it or die of exceptions; your choice.

One of the best things I've read for a long time .

The past is bickering over selfish personal freedoms, the future of is
unity.

And a tab is *exactly* four spaces. Not three. Not five. Not eight. For
you, for me, and for the rest of the world. Amen!

Thorsten

 

[Tim Chase]

4) Tabs remove the need for complicated

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

 

[Ian Kelly]

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.

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.

 

[Ian Kelly]

I hate  vertical white-space. I follow Python style guide suggestions,
and then some! I hate when people insert spaces into code blocks and
function/method bodies. If you feel a space must be inserted then that
is a good clue you should be using a comment there instead. Vertical
breaks should only happen before and after classes, methods,
functions, groups of GLOBALS, groups of import statements. Think of
func/method bodies as paragraphs and classes as sections of a book.
Two vertical spaces between classes and one vertical space between
func/methods.

You know, there is such a thing as a vertical tab. If we're going to
take your suggestion of mandating tabs (for greater freedom!), should
we not follow it to its logical conclusion and mandate the usage of
vertical tabs instead of multiple newlines? Then everybody could
choose for themselves how many lines they want a vertical tab to
represent

It should be MANDATED. And these @holes who refuse to format their
code in a community standard will suffer the plague of syntax errors.
Who do these people think they are? Do they believe the rules do not
apply to them? I'll tell you who they are, they are F'ING format
criminals.

I think I get it now. Your idea of "freedom" is that anybody can do
whatever they want as long as it's not illegal, and the ruling party
just makes anything it doesn't like illegal. In other words, a
monarchy.

 

[Thomas 'PointedEars' Lahn]

* Thomas 'PointedEars' Lahn (Sun, 17 Jul 2011 14:35:15 +0200)

*doublesigh* that is actually the point I was trying to make.

Well, you said you would "align code *by indenting*", which is either
nonsense following the not-so-uncommon definition of "indenting" that I
presented, or you chose a particularly bad example to make your point
(as it does not feature indentation at all).

From a programmer's point of view the distinction is artificial because he
does essentially the same: press the tab key

But he should not, unless he uses the Tab key to insert spaces, because the
*display width* of the Tab *character* is variable. *That* is the point!

or the indent button to move the stuff right from the cursor to the right
so it gets aligned with the stuff above.

"Indent button"?

 

[Dotan Cohen]

* Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300)


Alignment doesn't line up.

They do with tabs.

 

[rantingrick]

And a tab is *exactly* four spaces. Not three. Not five. Not eight. For
you, for me, and for the rest of the world. Amen!

Not *exactly*.

A tab is just a control char in a string that meant to convey a "user
defined space". When a text editor see's a tab in a string it uses the
current "user defined tab width" and creates the proper space (or
moves the proper distance) in the display. The tab control char
carries no information as to how WIDE a tab must be, no, the editor
makes that choice (based on user input or default).

However a tab can be EQUAL to four spaces, or eight spaces , or even
eight-eight spaces if the user wants it to.

The same is true for font. A string contains chars and the display
font is a decision for the editor to make (based on user input or
default).

We cannot always offer unity and freedom in a programming language.
But there are some exceptions; one of which being tabs.

 

[Dotan Cohen]

Not using a fixed-width font avoids this problem and others in the first
place.


I can recommend Consolas (Windows) or Inconsolata (elsewhere), which are
designed for programming and are near perfect in that regard.  However, I
have decided for "Deja Vu Sans Mono" for reading and writing Usenet articles
because it supports more Unicode characters and can be sized appropriately
for running text.

I have used those three in the past. Terrific fonts each of them,
especially Inconsolata if I remember correctly.

But, all of them are fixed-width fonts.  I do not understand how youcan
consider using a non-fixed-width font in programming "a real pleasure" as
many them show a lot of ambiguities in source code.  Take for example the
lowercase "l" (el) vs. the capital "I" (ai) vs. the "|" (pipe) character,
or the "0" (zero) vs. the capital "O" (oh) character in Arial.

The ambiguity has never been an issue for me. In the unlikely event
that an l (el) is in the place of a pipe, the code won't compile and
I'll get an error on the line in question. Though that has never
actually happened: the IDE is double-checking way before the code gets
to the compiler. Zero vs. O (oh), I've never had this issue either and
even if one key was hit in place of the other (they are close by) then
either the IDE or compiler would catch it, or it would result in a
minor bug in a text string.

It simply isn't an issue.

 

[Dotan Cohen]

When you find it Dotan, let me know, I've been looking since the later
'70's.

Hey there Gene! Are you not on every mailing list on the internet old man?!?

I have also come to the conclusion that the perfect woman, the perfect
physics theory, and the perfect programming font are all illusions
that men will stride their entire lives in search for but will never
find.

 

[Thorsten Kampe]

* Dotan Cohen (Sun, 17 Jul 2011 22:20:15 +0300)

They do with tabs.

Indentation alignment will (because you're using only spaces). Otherwise
it doesn't align (it can't), simply because of the "variable-width".

For instance (in a variable-width font):

if a == b:
var123 = 22
varxyz456 = 333
^^^^ ^^^^^
aligned not aligned

Thorsten

 

[Dotan Cohen]

Such a system of rigorous formatting rules requires much less
interpreter logic. Python will be leaner and meaner. There won't be
any more arguing about how to format code. There will only be one way;
the correct way! Choose to follow it or die of exceptions; your
choice.

Do you know that Python 4000 is the only language in the world whose
vocabulary gets smaller every year?'

 

[Dotan Cohen]

And a tab is *exactly* four spaces. Not three. Not five. Not eight. For
you, for me, and for the rest of the world. Amen!

Four is the number thou shalt indent, and the number of the indenting
shall be four. Six thou shalt not indent, neither indent thou two,
excepting that thou then proceed to four. Eight is right out.

 

[Waldek M.]

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

When you find it Dotan, let me know, I've been looking since the later
'70's.

For me, it's Terminus* (from sourceforge).

Br.
Waldek
[*] As long as you don't need anything but iso8859-1.

 

[Thomas 'PointedEars' Lahn]

That's because they were not invented as a means for programmers to vary
indentation.

Originally, tabs were a navigation device: When you press the tab key, you
skip ahead to the next tab column.

No, when you pressed the Tab key on a typewriter (BTDT), you advanced to the
next tab _stop_. This made it easier to write tables ("tab" from
"tabulate") on a typewriter (the alternative was time-consuming and error-
prone use of the space and backspace keys). With the evolution of the
(personal) computer, its use in offices and at home, and peripheral devices
like the dot matrix printer, typewriters fell out of common use, but the
terms associated with them were incorporated into information technology
language (cf. "TTY", originally "teletypewriter", e. g.).

The reason the tab stop is a full 8 positions: for faster navigation.

No, the reason is that table columns should be as far enough away from each
other to be distinguishable.

If it were 3 positions, it would take forever to skip from the start of
line to column 60. You'd appreciate that, if you were e.g. writing a
fiduciary report with some text to the left and two number columns to the
right, back in the day before spreadsheets and word processor tables.
Skip a column or two too far?

I am getting the idea here that you mean the right thing, but that you
explain it wrong.

 

[rantingrick]

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.

 

[Thomas 'PointedEars' Lahn]

[…] I do not understand how you can consider using a non-fixed-width
font in programming "a real pleasure" as many them show a lot of
ambiguities in source code. Take for example the lowercase "l" (el) vs.
the capital "I" (ai) vs. the "|" (pipe) character, or the "0" (zero) vs.
the capital "O" (oh) character in Arial.

The ambiguity has never been an issue for me. In the unlikely event
that an l (el) is in the place of a pipe, the code won't compile and
I'll get an error on the line in question. Though that has never
actually happened: the IDE is double-checking way before the code gets
to the compiler. Zero vs. O (oh), I've never had this issue either and
even if one key was hit in place of the other (they are close by) then
either the IDE or compiler would catch it, or it would result in a
minor bug in a text string.

It simply isn't an issue.

Apparently it is *has not been* an issue for *you* *yet*. There are
languages (like Python) that are compiled just-in-time. Besides, neither an
IDE nor a compiler can (always) recognize that foo["b0r"] is not foo["bOr"]
(which really is not a far-fetched example as the O and zero keys are
adjacent to each other on in keyboard layouts). You do not want such an
ambiguity to bite you later.

 

[rantingrick]

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?

 

[rantingrick]

You know, there is such a thing as a vertical tab.  If we're going to
take your suggestion of mandating tabs (for greater freedom!), should
we not follow it to its logical conclusion and mandate the usage of
vertical tabs instead of multiple newlines?  Then everybody could
choose for themselves how many lines they want a vertical tab to
represent

On the face of it one might think vertical tabs are a good idea
however newlines work just fine. There is no reason for expanding
vertical whitespace to create readble code. If you can offer a good
reason i'm listening. Also be sure to post links where others have
requested the same.

Besides, horizontal tabs are tied closely to distinguishing code
blocks. Vertical tabs do not have such a benefit. Instead of vertical
tabs we need strict rules on vertical code formatting. I intend to
draft AND implement such rules very shortly.

I think I get it now.  Your idea of "freedom" is that anybody can do
whatever they want as long as it's not illegal,

In a programming language yes. You're trying to draw correlations
between morality and law. In the arena of programming there is no such
thing as morality, only the law.

and the ruling party
just makes anything it doesn't like illegal.  In other words, a
monarchy.

What do you think we have now, a democracy? Does "Benevolent?-Dictator-
For-Life" ring a bell?

I can tell you one thing for sure. In MY version of Python everyone
will have a voice. That does not mean that EVERYONE will make the
final decision but EVERYONE's voice will be equally important. I can
also tell you this. I will not hide under the coat tails of my dev
team , NO, i will mingle with the people on my comp.lang.rickpy list.
Mats (Ruby's creator) will answer questions on comp.lang.ruby so why
does Guido refuse to acknowledge us here on comp.lang.python?