Tabs -vs- Spaces: Tabs should have won.

R

rantingrick

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

Tabs will align properly in variable width font if the editor is NOT
broken. When displaying a variable width font the editor should switch
from using the sum of N glyphs to a user defined total width in
absolute measurements (like millimeters). Alternatively if the editor
had to guess it could just use the widest glyph of the current set.

People, please stop using broken tools. If you stop using them people
won't keep producing them. Just imagine how great the world would be
if we could convince windows users!
 
D

Dotan Cohen

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.

I do agree that in a weakly-typed language such as python one might
conceivably try to use an undeclared variable and the IDE and compiler
won't catch that. However 0 vs. O would more likely be 0 vs. o as one
would really have to mess up bad to not only press the wrong key but
also hit shift at the same time. 0 and o are no harder to distinguish
in a VWF than in a FWF.

For that matter, why is it assumed that fixed-width fonts by nature
better distinguish 0 from O, or any other ambiguous characters? My
current system (Kubuntu 11.04, default VWF font in Firefox whatever it
may be) distinguished 0 from O just fine. Also I/1 and l/1 are easy to
distinguish, but I agree that I/l are not.
 
I

Ian Kelly

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

Gregory Ewing

Anders said:
Just like in the old days:)

Most editors can be configured to do that.

Where they fall down, in my experience, is that having inserted
those spaces, if you want to delete them you typically have to
backspace over them one at a time.

I don't enjoy that experience, which is why I have BBEdit Lite
set up to use tab-only indentation. If I'm feeling conscientious,
I convert to spaces before sharing the code with others. But tabs
work better for me given the tools I use and the way I like to
work.
 
C

Cameron Simpson

| > Originally, tabs were a navigation device: When you press the tab key, you skip
| > ahead to the next tab column.  The notion that whitespace characters are
| > inserted into the text would have been very alien to someone using text
| > processing software anno 1970.  Same thing with space and enter; on typewriters
| > the space bar doesn't "type" anything onto the paper, it moves to the next
| > column, and that thinking carried over to computers.
|
| And how much longer are we going to live in the past? Who cares about
| backward compatible tabs.

Anders was explaining, not supporting-for-the-future.

| Mandate the four space tab now! Mandate that
| Python takes four space and four space only! We shall lead the charge
| for universal tab unity in all programming languages.

You really don't know what you're talking about, do you? If Python
mandates this (hahaha!) the Perl crowd will immediately move to a more
advanced standard, likely 5 space indents (nicely decimalisable) while
indenting by two tabs (to flexibly leave room for more intermediate
logic to be inserted later with less diff noise, which they will find
hard to distinguish from program code).

| > The reason the tab stop is a full 8 positions: for faster navigation.  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.
|
| Just in case you were not aware this the year 2011. Spreadsheets have
| been around for a LONG time. Stop living the past.

The past was better. Always was and will be increasingly so in the
future. Stop fighting the tide!
 
I

Ian Kelly

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.

Okay:

1) Vertical tabs create freedom in the form of user controlled vertical spacing.

Vertical spacing height should be a choice of the reader NOT the author. We
should never "code in" vertical spacing height; but that is EXACTLY what we
are doing with newlines! No, the reader should be able to choose the
vertical spacing height without ANY formatting required or without any
collateral damage to the source code. Vertical tabs offer freedom,
newlines offer
oppression.

2) Vertical tabs remove the need for complicated newline-formatting tools.

With "vertical tabs only" you no longer need those fancy tools to add
the correct number of newlines between classes or methods.. THAT IS
EXACTLY WHY VERTICAL TABS
WHERE INVENTED! Why are we not using this technology? Why are we
continuing to promote newlines when vertical tabs are obviously more superior?

And as to why we should remove newlines:

3) Using only one vertical space token removes any chance of user error.

Unlike many syntactical errors, vertical space is invisible in a text/
source editor. Sure there are tools that can make vertical space visible,
however why do we constantly create asinine rules that force us to use
complicated tools when we could have choose vertical tabs and none of this
would have been a problem?

4) Vertical tabs maintain unity in the source code base.

When we replace "newlines only" with "vertical tabs only" we maintain
a code base that promotes unity and
not conformity. There shall not be any "inconsistent vertical spacing
errors" due to mixing vertical tabs and newlines. Also we can avoid
adding multiplicity
to the compiler. The compiler will not have to consider BOTH vertical tabs AND
newlines as valid vertical spacing tokens, only vertical tabs. The
logic would be much
simpler.
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.

Vertical spacing helps to visually separate classes from other
classes, and methods from other methods.
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.

You have been drawing the same correlation from your very first post
where you stated, "Tabs offer freedom, spaces offer oppression."
What do you think we have now, a democracy? Does "Benevolent?-Dictator-
For-Life" ring a bell?

I don't see Guido going around making ridiculous pronouncements about
what forms of indentation are acceptable (beyond the standards that
are set and expected for the standard library, that is). He could
have made the language space-only from the very beginning. He didn't;
that should tell you something. He also could have insisted that the
parser only accept source written in the ISO-8859-1 encoding "for
unity and freedom", but he didn't. Or he could have stated "absolute
imports only" from the very beginning, and yet even in Python 3 where
the old-style relative imports have been removed, relative imports are
still available to be used.
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.

Thanks, but I won't be needing a voice, because your version of Python
will clearly be too limiting from the ground up for me to have any
interest in using it in the first place.
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?

Probably for the same reason that (I presume) he doesn't spend all day
answering Python questions on stackoverflow or responding to comments
about Python on slashdot: he can get more done in his actual job by
unsubscribing.

If you want to have input on Python, all you have to do is subscribe
to python-dev. Of course, it *is* a moderated list, so if you make as
much of a nuisance of yourself over there as you do here, they might
kick you out.
 
A

Andrew Berg

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

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.
That reminds me of Full Metal Jacket.
"Here you are all equally worthless."

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

iQEcBAEBAwAGBQJOI22xAAoJEPiOA0Bgp4/LIwsIANrgRO1m4f2w4M6HQ0I2Ysjl
SqSCQ4r4p7ZG4O6t/ms6r3uVQXh7FrV1atkWLkUprwd+DfPTl2Lpp5xF7RB2lJ4/
pvcIWQ47kC2F4BgbcW2UN8E1vu6K1G+q/s81HzXsTfdnFqYBrhli+Hd3XvgFH9Zr
nt8dKJuX1lVowYeg22iZyUiMaubpZl35Xyw4xFTPJ7eW8ynHriYG3JfJtUVjDYz0
Hs4oXrdcllugOwYcGUN4tddJ1uls/Xat16HUtxOIYIJUQr1kZVa/l0kmsoi1AT1/
SBCnLzyiuBLA8fHcvE675+/834FZi9sgAPOM4HY/dx3YDa8musSjbPtfSUFAQKQ=
=NEuJ
-----END PGP SIGNATURE-----
 
A

Andrew Berg

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

Why do you feel the need to layout your code in a "GUI-listview"
manner. Next you'll want column titles and column sorting... Jeez!
This is what you should have done...
I was testing my psychic abilities. I had the feeling that such a layout
would irritate you, so I had to try it. Before, I thought this psychic
stuff was all hokey, but now...

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

iQEcBAEBAwAGBQJOI25rAAoJEPiOA0Bgp4/L5lwIAIxwvAz7QBEOaQ9Hn/Er7esE
t4A76iJMOzVajFD61Wf8HkCyBrkQPk2i7koUqByUbQMRjAD3ukBorH+RNlfYwdJQ
w2HGjxCG36fA9yYZe5N+ySX1UlxH4pbZJLDxJMvo4brF8XVVOknsQyIW3rPM2ma9
CtdP4pWRpuE+4mz+wu4uxZW0xFarFV64TbcsXs1aZZAUSSJ4HUEbSuk/gw4IGBc5
HrOCBKt9hlgB7oh6KyITikFHCWV63iDzqfkVxP7Cr7ON3KaMPcfEVe2JowZv8NeV
cZmr4pbxWQ+ya0i8ukGjizrUa+Jdjp0p3I1OsVlZ0NCLyp4v5zDVS6R+97zjVc4=
=lBEF
-----END PGP SIGNATURE-----
 
R

Roy Smith

Ian Kelly said:
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.
 
A

Andrew Berg

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

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.
I think the reason the idea isn't dead is because of the emergence of
new devices with small displays (tablets/smartphones/etc.) and their
increasing popularity. When writing code that is meant to be run on
desktops or servers, the 80-column limit is mostly irrelevant, but
Python running on these small devices, especially with Python code being
interpreted rather than compiled, it's convenient to edit code on those
platforms, where there is a significant column limit.

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

iQEcBAEBAwAGBQJOI3aPAAoJEPiOA0Bgp4/LRMQH/irglKlq7+Nk67dvGuQt39ZH
nHqEE4HG5J7y/JfW+3g4UbhISHFwsJO0yvvcUN8cfLQ9O4KxzR65PS6Jqs8KEWS+
04hAZl0AbEKHZv3nOxWhxvAF5saJnq0xWHAtE9tFwS31I7Oh65rCBZD4g9BFiCql
YeTAklPB64Ik6F+7kcLDx3xDn6CPb/03Nj2assGatSUEY5p0OqzZ9nPnBxifLDFC
piOkZOgPW39s/zEzr+0LiD3ayFmtPoYldBFR0c7qkzyN6aS+Fur4kqbxlGl4jbI/
Xkms/5yrie/jAf4HgcaMHX2l4Or/dY7jyb6cK+How+yNa76xh6CZdxIZ68oR6Fs=
=K9SY
-----END PGP SIGNATURE-----
 
R

Roy Smith

Andrew Berg said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


I think the reason the idea isn't dead is because of the emergence of
new devices with small displays (tablets/smartphones/etc.) and their
increasing popularity. When writing code that is meant to be run on
desktops or servers, the 80-column limit is mostly irrelevant, but
Python running on these small devices, especially with Python code being
interpreted rather than compiled, it's convenient to edit code on those
platforms, where there is a significant column limit.

Can you give me a more specific example? I assume there's nobody (at
least nobody sane) editing Python source code on iPhones. I'll admit
I'm not that familiar with the plethora of tablets and handheld devices
out there. Are there really devices which impose exactly an 80-column
width?
 
A

Andrew Berg

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

Can you give me a more specific example? I assume there's nobody (at
least nobody sane) editing Python source code on iPhones.
I haven't done it myself, but there are plenty of Python projects out
there made for mobile devices, and I would imagine the convenience of
editing on the platform itself to test things immediately outweighs the
inconvenience of a small display and tiny keyboard.
Are there really devices which impose exactly an 80-column width?
Font size can be changed, so it's not a matter of a fixed number of
characters, but rather how many characters can fit on such a small
display at a reasonable size. My guess is that 80 is pretty arbitrary
nowadays, but it's much easier to stick with 80 than debate over it,
especially when display sizes vary so greatly among these devices.

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

iQEcBAEBAwAGBQJOI4LnAAoJEPiOA0Bgp4/L9s4H/1hZUtzSUEK3ZCs/+5SQk4dE
W7Au9Gv4rpNK6zmIRTmWkBeqUZdJHVXftQslnkvVr+pUMjz395YZbT3a2rAiaMje
IYq2HqKk8kZAeVo1sQLlKAl5PcCP8yJKGW1UJBLcLarXC33e/3pB1M7MY3QIVEta
S68IsBR5RJdtNIOJcmNtYEglPe1CSXt0LeEGYoseBhz9UyUDnnJlelu6WRAatKxR
jB8sbaWN4wLdT1iFkNFePSA1hJQSGmot0D5UaYTTG5HuG4JNlSeTZ23ctFLph/XG
96vndHBjxkDEdzCBkxSRaM5i5W/vSa/t25c5uDvXibldrxBWqm2QYJTeMhJ9JsY=
=6RXz
-----END PGP SIGNATURE-----
 
A

Andrew Berg

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

I should also mention that this mostly speculation on my part, and that
I would love to hear from someone who develops for these devices.

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

iQEcBAEBAwAGBQJOI4NvAAoJEPiOA0Bgp4/LI8UH/3s+YyOsRGfHmcfX17glGUPT
bMAHq7vkmyWp5/zdcTWiRSxySrmTdcBJlquQOzUXhzGjRJlDoRQJrVypNr5zEO/r
FQkqwSnd0MmAg7wQX5I8xnM+muqeqOMvSqPs6HzBUiUqgwNoMlDn1v0Cc0h72mxx
Nf5r67/0Sptg7sR15aZnLtDodfql6qDxbIbDBdsp6SVnL6XE3l2NfFnB8DcOXRXk
2ooiV5/HlV0S2lr5TiKshyWuumQCnOPg6+ZDc//vev4L3aeM6EAXtYTWTWJEERl+
6PMP6u1SmA7P43jjzunxTiyXRkLLp7lJDaoWVzb3o+FDLOwNhgVEUH28TiXuNgQ=
=0HaP
-----END PGP SIGNATURE-----
 
S

Steven D'Aprano

Chris said:
[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.

Put your money - or, in this case, development time - where your big
ranting mouth is. Prove that your ideas are worth something by acting
on them.

Ha ha, oh that's hilarious!!!

Back in 2007, a n00b calling himself "TheFlyingDutchman" who I am
*reasonably* sure was Rick decided to fork Python:

http://mail.python.org/pipermail/python-list/2007-September/1127123.html

Then in 2010, Rick promised that if the Python developers didn't bow to his
demands, he would folk Python, and the silent majority who agreed with him
but were too terrified to say so publicly would drop CPython in a flash and
follow him.

Thread starts here: read and weep.

http://www.gossamer-threads.com/lists/python/python/835227?do=post_view_threaded#835227

How's that fork going Rick? Written a single line of code yet?
 
S

Steven D'Aprano

Roy said:
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.

I agree! Which is why I set my line width to 78 columns.
 
M

Mel

Andrew said:
I should also mention that this mostly speculation on my part, and that
I would love to hear from someone who develops for these devices.

There's a mailing list for Python scripting on Android --
List-Subscribe: <http://groups.google.com/group/python-for-
android/subscribe?hl=en_US>, <mailto:python-for-
(e-mail address removed)>
.. Tends to be pretty detail-oriented.

Mel.
 
M

Mel

Andrew said:
I should also mention that this mostly speculation on my part, and that
I would love to hear from someone who develops for these devices.

There's a mailing list for Python scripting on Android --
List-Subscribe: <http://groups.google.com/group/python-for-
android/subscribe?hl=en_US>, <mailto:python-for-
(e-mail address removed)>
.. Tends to be pretty detail-oriented.

Mel.
 
S

Steven D'Aprano

Steven said:
I agree! Which is why I set my line width to 78 columns.

Sorry, that looks like a troll, but isn't.

I seriously do set my editor to a soft limit of 78 characters. That is, I
can exceed it if I want, but almost never do.

Why 78? Because it's one less than 79, as mandated by PEP 8, and two less
than 80, the hoary old standard. The reasons given in PEP 8 for 79 make
sense to me, and I don't like reading really long lines of code. With one
exception, if your line of code needs more than 79 plus or minus 1
characters, chances are it is doing too much.

The exception is, you have an indented block of code, perhaps three or four
indents deep (surely you never allow anything to get beyond five or six
indents?), and you want to raise an exception:

raise SomeExceptionType("and here's a rather long error"
"message blah blah blah")

If I only go a character or two over, I might be tempted to just go over.
But normally I split the line, as above, and use implicit line
concatenation.


http://www.python.org/dev/peps/pep-0008/
 
A

Andrew Berg

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

Then in 2010, Rick promised that if the Python developers didn't bow
to his demands, he would folk Python, and the silent majority who
agreed with him but were too terrified to say so publicly would drop
CPython in a flash and follow him.

Thread starts here: read and weep.

http://www.gossamer-threads.com/lists/python/python/835227?do=post_view_threaded#835227

How's that fork going Rick? Written a single line of code yet?
I skimmed through the first post a bit and it's hilarious. TL;DR for
now, but I'll read the whole thread later. I'm still surprised how much
entertainment I get from a programming language newsgroup.

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

iQEcBAEBAwAGBQJOI4vQAAoJEPiOA0Bgp4/LiN4IAMFXmBUxLOr1lYRIVY7kSwWj
Ln+pTvOR6S0og6S1v1fljTeFy8NWsbeLHjF48TahJf5VlEqiuCd7zUQ8r0gDn6ut
+ibDz+rtJJAE2XOG5myBylwcuG31TuaoXcSsNMCTnIMi6ZsoOWeBmkD0rvG66eFM
tPaceBdv7qe/0oNcy/DalEZ8gE2NSfrm6u4g5RQge8E4o4IwCWwMdSOkKRjkJdix
mbCfcCytQtc+X7IFwuUcFMAtFq9f8rzp8Jl45/wCBlxBPvZbLfqJvit9J8hgF81v
KgSeyV9BLKgzRamBOZQdG2/mUwJV8aQwxdSJrtRwZ0YWpQaOPnTZlQsRyAzf4nw=
=9zSp
-----END PGP SIGNATURE-----
 
T

Teemu Likonen

* 2011-07-18T10:54:40+10:00 * Steven D'Aprano said:
Back in 2007, a n00b calling himself "TheFlyingDutchman" who I am
*reasonably* sure was Rick decided to fork Python:

http://mail.python.org/pipermail/python-list/2007-September/1127123.html

I don't know if they are the same person but quite recently
"TheFlyingDutchman" tried to understand symbols, variables' scope,
bindings as well as function and variable namespaces in Common Lisp. It
resulted in a long thread, some of it was quite interesting.

http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/36000a1f37ebb052/5683597dd587fa87
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top