do people really complain about significant whitespace?

[infidel]

Where are they-who-hate-us-for-our-whitespace? Are "they" really that
stupid/petty? Are "they" really out there at all? "They" almost sound
like a mythical caste of tasteless heathens that "we" have invented.
It just sounds like so much trivial nitpickery that it's hard to
believe it's as common as we've come to believe.

[Jason]

infidel wrote:

Where are they-who-hate-us-for-our-whitespace? Are "they" really that
stupid/petty? Are "they" really out there at all? "They" almost sound
like a mythical caste of tasteless heathens that "we" have invented.
It just sounds like so much trivial nitpickery that it's hard to
believe it's as common as we've come to believe.

I have a coworker who dislikes Python for the whitespace. He likes the
idea that if someone is silly enough to put a whole program on one
line, they can put it back together by following the braces. He also
likes that the compiler can compile the program even if a normal person
can't read it.

I've pointed out that we format our code with the whitespace anyway.
He points out that if some code gets accidentally dedented, it is
difficult for another programmer to determine which lines were supposed
to be in the indented block. I pointed out that if someone
accidentally moves a curly brace, the same problem can occur.
Anecdotally, I've never had either problem.

Sadly, people who do dislike the whitespace do exist. I have also
talked with several other programmers who were very turned off about
the white-space thing and wouldn't give the language a chance.

Eric S. Raymond wrote enthusiastically about Python, but was initially
turned off by the whitespace rules. (See
"http://www.python.org/about/success/esr/" for details.)

I personally love that my logically formatted code imparts information
logically to the language.

(I haven't seen a good hate-us-for-our-whitespace thread go on for
awhile. I do remember some good "We like Python, Now Add Our Favorite
C/C++/LISP/INTERCAL Features or We'll Leave" threads on this newsgroup.)

[crystalattice]

infidel wrote:

Where are they-who-hate-us-for-our-whitespace? Are "they" really that
stupid/petty? Are "they" really out there at all? "They" almost sound
like a mythical caste of tasteless heathens that "we" have invented.
It just sounds like so much trivial nitpickery that it's hard to
believe it's as common as we've come to believe.

Actually, some of the guys I work with complained about Python when
they first had to learn it for our Zope server. One of them is an
old-school Unix guy who spent the last 20+ years doing procedural
languages with funky syntax, like C. The other one is a VB.NET junkie
who I don't think has much experience outside of MS languages, except
maybe Java.

One of the complaints they had for the first few weeks was the white
space issue and the fact Python doesn't have brackets or semicolons.
Obviously they learned to "deal with it" but they sure made it seem
like it was a painful transition. I think the biggest pain was the
fact that they are forced to indent their code now so they can't be
lazy anymore.

[John Machin]

infidel wrote:

Where are they-who-hate-us-for-our-whitespace? Are "they" really that
stupid/petty? Are "they" really out there at all? "They" almost sound
like a mythical caste of tasteless heathens that "we" have invented.

All societies demonise outsiders to some extent. It's an unfortunate
human (and animal) trait. In some societies, this is directed from the
top. Very fortunately, this is AFAICT not the case in the Python
community.

It just sounds like so much trivial nitpickery that it's hard to
believe it's as common as we've come to believe.

So just block your ears when the propaganda vans with the loud-speakers
on top drive past your dwelling :-)

........................................

However, meaninglessly significant whitespace at the *other* end of a
line can be annoying:

#>>a = \
.... 1
#>>a
1
#>>b = \
File "<stdin>", line 1
b = \
^
SyntaxError: invalid token

Huh? Can't see what the problem is? Maybe this exaggerated example may
help:

#>>c = \
File "<stdin>", line 1
c = \
^
SyntaxError: invalid token

Cheers,
John

[bearophileHUGS]

Jason wrote:

He points out that if some code gets accidentally dedented, it is
difficult for another programmer to determine which lines were supposed
to be in the indented block. I pointed out that if someone
accidentally moves a curly brace, the same problem can occur.

I like significant whitespace, but a forum, newsgroup manager (like
Google Groups in the beginning), email management program, blog comment
system, etc, may strip leading whitespace, and it usually doesn't
"move" braces. A language (like Python) doesn't exist alone in vacuum,
it exists in an ecosystem of many other programs/systems, and if they
don't manage leading whitespace well, such language may have some
problems :-)

Bye,
bearophile

[Jason]

be************@lycos.com wrote:

Jason wrote:

He points out that if some code gets accidentally dedented, it is
difficult for another programmer to determine which lines were supposed
to be in the indented block. I pointed out that if someone
accidentally moves a curly brace, the same problem can occur.

I like significant whitespace, but a forum, newsgroup manager (like
Google Groups in the beginning), email management program, blog comment
system, etc, may strip leading whitespace, and it usually doesn't
"move" braces. A language (like Python) doesn't exist alone in vacuum,
it exists in an ecosystem of many other programs/systems, and if they
don't manage leading whitespace well, such language may have some
problems :-)

Bye,
bearophile

Certainly, you are correct. Most of the time, I zip up any source code
for email purposes. But newsgroup managers are certainly an issue.
For comment thingies online, the preformat tag is your friend, too.

It is annoying that certain communication channels do not respect
white-space. I dislike using braces because I have to indicate my
intentions twice: once for the compiler and once for humans.

In the situations where I use Python, though, I haven't had a problem.
In the situations where my coworker is using Python (code updates
through CVS), he also shouldn't have a problem.

[Ben Finney]

"infidel" <sa***********@gmail.comwrites:

It just sounds like so much trivial nitpickery that it's hard to
believe it's as common as we've come to believe.

As others have pointed out, these people really do exist, and they
each believe their preconception -- that significant whitespace is
intrinsically wrong -- is valid, and automatically makes Python a
lesser language.

One of the most stupid language-definition decisions that most people
have come across is the Makefile format. If you're not familiar with
it, spaces and tabs are *each* significant. Specifically, putting
spaces where a tab is required will result in a file that, while it
may be visually identical to a correctly formatted file, doesn't parse
correctly. In hindsight it's trivial to predict the needlessly painful
learning process that ensues.

This is a very painful memory for many programmers, and the general
opinion that results is "syntactically significant whitespace is
bad". This is the phrase that always gets brought out, and it's often
clear that the person hasn't considered *why* it's bad.

The issue with the Makefile format (lampooned wonderfully by the
Whitespace programming language) is that *invisible* differences in
whitespace should not be significant. In a Makefile, you *must* mix
spaces and tabs in the same file; this leaves the door wide open to
invisible differences. In Python, an admonishment of "always indent
each file consistently" suffices.

Hope that goes some way to explaining one possible reason why rational
people can consistently react in horror to the issue.

--
\ "Friendship is born at that moment when one person says to |
`\ another, 'What! You too? I thought I was the only one!'" -- |
_o__) C.S. Lewis |
Ben Finney

[bearophileHUGS]

Jason wrote:

But newsgroup managers are certainly an issue.
For comment thingies online, the preformat tag is your friend, too.

Time ago I used to add a | or something similar at the beginning of
lines, to avoid the leading whitespace stripping done by Google Groups.
Other (silly) solutions are to add explicitely the number of indents at
the beginning of a line (2 digits suffice), or to even add explicit
#end comments just under the dedents, so a script can read such ending
comments and reconstruct the original Python indentations... (lines
splitted with \ and similar require some extra care).

Bye,
bearophile

[Jim]

He points out that if some code gets accidentally dedented, it is

difficult for another programmer to determine which lines were supposed
to be in the indented block. I pointed out that if someone
accidentally moves a curly brace, the same problem can occur.
Anecdotally, I've never had either problem.

I have many times found that in moving a multi-screen block of code
from one place to another (where the indent is less or more) then I
have trouble re-indenting the code. That is not to say that I don't in
the end prefer the significant whitespace, but I have had errors moving
code like:
if ..
try:
..
except
..
else ..
where it wound up (with the help of the emacs tab key) as
if ..
try:
..
except
..
else ..
.. I attempt to be careful, but certainly it has happened to me.

Jim

[Michiel Sikma]

Op 8-aug-2006, om 1:49 heeft Ben Finney het volgende geschreven:

As others have pointed out, these people really do exist, and they
each believe their preconception -- that significant whitespace is
intrinsically wrong -- is valid, and automatically makes Python a
lesser language.

Well, I most certainly disagree with that, of course, but you gotta
admit that there's something really charming about running an auto-
formatting script on a large piece of C code, turning it from an
unreadable mess into a beautifully indented and organized document. I
actually sometimes intentionally programmed ugly code so that I could
do that. I kind of miss it. :)

Michiel

[Bruno Desthuilliers]

infidel wrote:

Where are they-who-hate-us-for-our-whitespace?

You may find some on comp.lang.ruby...

[gslindstrom]

infidel wrote:

Where are they-who-hate-us-for-our-whitespace? Are "they" really that
stupid/petty? Are "they" really out there at all? "They" almost sound
like a mythical caste of tasteless heathens that "we" have invented.
It just sounds like so much trivial nitpickery that it's hard to
believe it's as common as we've come to believe.

Some of it may be a reaction from "old-timers" who remember FORTRAN,
where (if memory serves), code had to start in column 16 and code
continutations had to be an asterik in column 72 (it's been many years
since I've done any work in FORTRAN, but you get the idea)

Or it may be a reaction from Assembler, which is also quite
column-centric (is Assembler still taught in schools??).

But most likely, it's different. It's easier to complain about things
than to actually check them out. Recently I had a friend tell me that
they absolutely hated a certain tv personality/author. When I asked if
they had ever watched the person or read one of their books, they said
"Why should I? I hate them!!". I think the same attitude comes into
play with computer languages.

One more thing. I have many friends that love to program Perl.
Without bashing the language, I find it ironic when they say "There's
more than one way to do it" but inisit that I should be using Perl
while they quote Python as "There's only one way to do it" though
(most) Python coders I know are fairly comforatble dealing with
multiple languages.

--greg

[infidel]

One of the most stupid language-definition decisions that most people

have come across is the Makefile format.

<snippage/>

Hope that goes some way to explaining one possible reason why rational
people can consistently react in horror to the issue.

Ah, thanks for that. This peek into history makes the irrational fear
of significant whitespace seem a little less irrational.

[infidel]

All societies demonise outsiders to some extent. It's an unfortunate

human (and animal) trait.

Which is why I questioned it.

So just block your ears when the propaganda vans with the loud-speakers
on top drive past your dwelling :-)

Funny how using python makes me feel like a member of some kind of
rebellion against the empire. Where I work it's all VB, VB.NET, and
ASP.NET. I've been the lone voice in the wilderness for so long that
I've become an inside joke. I actually have a certificate that says
"Most likely to re-write the system in Python".

*sigh*

[Thomas Guettler]

Am Mon, 07 Aug 2006 14:43:04 -0700 schrieb infidel:

Where are they-who-hate-us-for-our-whitespace? Are "they" really that
stupid/petty? Are "they" really out there at all? "They" almost sound
like a mythical caste of tasteless heathens that "we" have invented.
It just sounds like so much trivial nitpickery that it's hard to
believe it's as common as we've come to believe.

I like python, but sometimes i don't like that python allows
spaces and tabs. It would be easier if you had less choice and
must use four spaces.

That's one small argument against the current whitespace syntax in python.

Thomas

[Alex Martelli]

<gs*********@gmail.comwrote:

infidel wrote:

Where are they-who-hate-us-for-our-whitespace? Are "they" really that
stupid/petty? Are "they" really out there at all? "They" almost sound
like a mythical caste of tasteless heathens that "we" have invented.
It just sounds like so much trivial nitpickery that it's hard to
believe it's as common as we've come to believe.

Some of it may be a reaction from "old-timers" who remember FORTRAN,
where (if memory serves), code had to start in column 16 and code
continutations had to be an asterik in column 72 (it's been many years
since I've done any work in FORTRAN, but you get the idea)

Column 7 was the start, 6 the one for continuation; 1-5 and 73-80 were
ignored by the compiler and could be used for numbering, grouping &c.
Been many years in my case, too, but as I was a mainly-Fortran guru for
several years in my career, it's hard to forget;-).

Or it may be a reaction from Assembler, which is also quite
column-centric (is Assembler still taught in schools??).

I never used a column-centric Assembler: even the first assemblers I
used, in the '70s (6502, Z80, a mini called HP1000, VAX/VMS when it was
just out, BAL/370, ...) were all column-indifferent. The HP1000 did not
even have a punched-card reader: it used punched _tape_ instead (quite a
popular device then, as it came with teletypes typically used as
consoles), so keeping track of columns would have a royal mess:-).

I'm pretty sure you're still _able_ to take SOME Assembler-based course
in most universities, but you need to strive pretty hard for the
purpose... it's definitely not in the "default curriculum", even for
EEs, much less CSs.
Alex

[Aahz]

In article <11**********************@m79g2000cwm.googlegroups .com>,
infidel <sa***********@gmail.comwrote:

>
Where are they-who-hate-us-for-our-whitespace? Are "they" really that
stupid/petty? Are "they" really out there at all? "They" almost sound
like a mythical caste of tasteless heathens that "we" have invented.
It just sounds like so much trivial nitpickery that it's hard to
believe it's as common as we've come to believe.

When I put on my Python evangelist hat, I do get complaints about that
regularly.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." --Brian W. Kernighan

[Andy Dingley]

Thomas Guettler wrote:

I like python, but sometimes i don't like that python allows
spaces and tabs. It would be easier if you had less choice and
must use four spaces.

That's the nice thing about Python. It doesn't care about indentation
distance, it just wants "some" and "consistent".

I like the idea that "humans see the whitespace as significant anyway,
so document the fact and use it" (I presume this came from Occam).
What I don't like so much is that the _ends_ of blocks are less
visually obvious.

[Gerhard Fiedler]

On 2006-08-08 12:49:35, Aahz wrote:

>>Where are they-who-hate-us-for-our-whitespace? Are "they" really that
stupid/petty? Are "they" really out there at all? "They" almost sound
like a mythical caste of tasteless heathens that "we" have invented.
It just sounds like so much trivial nitpickery that it's hard to
believe it's as common as we've come to believe.

When I put on my Python evangelist hat, I do get complaints about that
regularly.

Being new to Python, and the indenting thing being the one feature that
convinced me to take a serious look at Python, there's almost only one
conclusion for me: they must not like self-documenting code... :)

Gerhard

[Stephen Kellett]

In message <ma***************************************@python. org>,
Gerhard Fiedler <ge*****@gmail.comwrites

>conclusion for me: they must not like self-documenting code... :)

Oh dear. So if the code is wrong it is self documenting?

Comments document what the code should do.
The code shows what the code actually does.

Also from a maintenance perspective reading comments is a lot faster
than reading the code. For a whitespace significant language this can be
very helpful when the formatting gets mangled for some reason.

There is no such thing as self-documenting code.

People that say they don't need to document their code because its self
documenting - no hire. I've been writing and selling software for 23
years now and I still keep hearing this bull about self documenting
code. Sigh.

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting

[Carl Banks]

Michiel Sikma wrote:

Op 8-aug-2006, om 1:49 heeft Ben Finney het volgende geschreven:

As others have pointed out, these people really do exist, and they
each believe their preconception -- that significant whitespace is
intrinsically wrong -- is valid, and automatically makes Python a
lesser language.

Well, I most certainly disagree with that, of course, but you gotta
admit that there's something really charming about running an auto-
formatting script on a large piece of C code, turning it from an
unreadable mess into a beautifully indented and organized document.

The only time I get that satisfaction is when I run the formatter to
format some C code I'm asked to debug. Quite often the problem was
something that could have been easily spotted if the coder had used
good indentation in the first place. Though they probably wouldn't
have seen it anyways, considering the poor programming skills of most
engineers (the classical definition, not computer engineers).

The very fact the code formatters exist should tell you that grouping
by indentation is superior.
Carl Banks

[Gerhard Fiedler]

On 2006-08-08 19:02:27, Stephen Kellett wrote:

In message <ma***************************************@python. org>,
Gerhard Fiedler <ge*****@gmail.comwrites

>>conclusion for me: they must not like self-documenting code... :)

Oh dear. So if the code is wrong it is self documenting?

?? I'm not sure you are actually responding to what I wrote. I did not make
any affirmation about a relationship between correctness of code and its
self-documenting properties.

Comments document what the code should do.
The code shows what the code actually does.

That's only in theory like this, and then only in a bad theory. I'm sure in
23 years you have seen as many code comments as I have that documented what
a previous version of the code should have done...

Also from a maintenance perspective reading comments is a lot faster than
reading the code.

This depends a lot on the code, the comments and the reader. I prefer code
that reads as fast or faster than inline comments and coders that read code
as fast as comments :)

(I'm not talking about useful header comments. But even these can be made a
lot more succinct through appropriate coding.)

There is no such thing as self-documenting code.

But there is well-written code that is as much as reasonably possible
self-documenting, meaning easy to read and understand, with a clear
structure, helpful names, appropriate types (where applicable) etc etc.
Come on, if you have been in the business for 23 years you know what I
mean.

"Self-documenting" -- as used by me -- is always meant as a goal to be
approached gradually, not a state where you are or not; "as much as
possible" is always implied, the question is "more or less" not "whether or
not". I thought that was somehow obvious... :)

People that say they don't need to document their code because its self
documenting - no hire.

People that need a line of comment for every line of code -- no hire either
:) It's the right balance.

This is not really a subject for quick shots. And it is utterly off-topic
for my post.

Here's the long version of what I wrote:

Python's indent-based code structure is more self-documenting than for
example the brace-based structure of C in the following way. In C, it is
common practice to document the code structure by indenting. Indenting in C
is mere /documentation/ -- it is not required for the code to work as
written, but it is required (or commonly considered required) to document
its structure. When done properly, it's part of the "self-documentation" of
C code: you don't write a bunch of white space-stripped C and then document
the structure of that blob; you document the structure in the code by
correctly indenting it. However, it is easy to write C code where the
indenting and the structure are out of sync. (I know that there are tools
for that, but still...) In Python, the indenting is not a documentation
convention dissociated from the code structure, it /is/ the code structure.
In that sense, Python code is more "self-documenting" than C.

Gerhard

[Slawomir Nowaczyk]

On Mon, 07 Aug 2006 16:47:57 -0700
Jason <te***********@gmail.comwrote:

#It is annoying that certain communication channels do not respect
#white-space. I dislike using braces because I have to indicate my
#intentions twice: once for the compiler and once for humans.

I must admit I do not get this "indicate intentions twice" argument,
even though I heard it a number of times now... It's not that braces
require more work or more typing or something, after all -- at least
not if one is using a decent editor.

Really, typing brace after function/if/etc should add newlines and
indent code as required -- automatically. Actually, for me, it is even
*less* typing in C and similar languages... I probably should teach my
Emacs to automatically add newline after colon in Python, just as it
does after a brace in C... As soon as I figure out how to deal with
dictionary literals. Hmmm.

--
Best wishes,
Slawomir Nowaczyk
( Sl***************@cs.lth.se )

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[brianmce]

Slawomir Nowaczyk wrote:

>
I must admit I do not get this "indicate intentions twice" argument,
even though I heard it a number of times now... It's not that braces
require more work or more typing or something, after all -- at least
not if one is using a decent editor.

Its not the typing, its the fact that when you say the same thing
twice, there is the potential for them to get out of sync. If the
method the compiler uses (braces) and the method the human uses
(indentation) to determine what the code does don't agree, then a
reader will be likely to misunderstand what it will actually do. One
of the driving principles behind Python is that, because code will be
read more often than written, readability is more important.

[Pierre Barbier de Reuille]

Carl Banks wrote:

Michiel Sikma wrote:

>Op 8-aug-2006, om 1:49 heeft Ben Finney het volgende geschreven:

>>As others have pointed out, these people really do exist, and they
each believe their preconception -- that significant whitespace is
intrinsically wrong -- is valid, and automatically makes Python a
lesser language.

Well, I most certainly disagree with that, of course, but you gotta
admit that there's something really charming about running an auto-
formatting script on a large piece of C code, turning it from an
unreadable mess into a beautifully indented and organized document.

The only time I get that satisfaction is when I run the formatter to
format some C code I'm asked to debug. Quite often the problem was
something that could have been easily spotted if the coder had used
good indentation in the first place. Though they probably wouldn't
have seen it anyways, considering the poor programming skills of most
engineers (the classical definition, not computer engineers).

The very fact the code formatters exist should tell you that grouping
by indentation is superior.
Carl Banks

Problem being : grouping by indentation do *not* imply good indentation.
For example, I had to read a piece of (almost working) code which looked
like that :
if cond1 : stmt1
stmt2
stmt3
if cond2: stmt4
stmt5
elif cond3: stmt6
stmt7
else: stmt8
stmt9
stmt10
stmt11

So you can tell what you want, but this code is valid but impossible to
read and impossible to reindent correctly. So although I personnaly like
Python, I still don't think meaningful indentation is good.

Pierre

[Brett g Porter]

br******@gmail.com wrote:

Its not the typing, its the fact that when you say the same thing
twice, there is the potential for them to get out of sync. If the
method the compiler uses (braces) and the method the human uses
(indentation) to determine what the code does don't agree, then a
reader will be likely to misunderstand what it will actually do. One
of the driving principles behind Python is that, because code will be
read more often than written, readability is more important.

Not to mention the errors that creep in when code is maintained, like
when C code starting out as

if (i < SOME_CONSTANT)
doSomething();

gets "maintained" to

if (i < SOME_CONSTANT)
doSomething();
doSomethingDangerous();

without the programmer adding the surrounding braces. The programmer's
intent is clear to me as a human, but the C compiler will disagree with
me, and in this case, the compiler will be right and I'm wrong.

You can (and we do, at my company) have coding standards that mandate
braces around single line if()s in C/C++, but that's really just
patching around the problem (and it counts on humans being consistent).

Pushing the scutwork down onto tools is not as good a solution as
eliminating the scutwork, especially when it shouldn't be necessary at
all...


--
// Brett g Porter * bg*@bgporter.net
// http://www.bgporter.net/blog

[Stephen Kellett]

In message <11**********************@p79g2000cwp.googlegroups .com>,
"br******@gmail.com" <br******@gmail.comwrites

>of the driving principles behind Python is that, because code will be
read more often than written, readability is more important.

In which case, for long functions with multiple levels of indentation
Python fails compared to languages that use braces or END or end; etc.

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting

[skip]

>of the driving principles behind Python is that, because code will be
read more often than written, readability is more important.

StephenIn which case, for long functions with multiple levels of
Stephenindentation Python fails compared to languages that use braces
Stephenor END or end; etc.

No. In that case Python makes it more readily apparent that your code is
too complex. With C, Java, C++, Perl or FORTRAN you just smush everything
over to the left and pretend it's not. ;-)

Skip

[Stephen Kellett]

In message <ma***************************************@python. org>,
Gerhard Fiedler <ge*****@gmail.comwrites

>But there is well-written code that is as much as reasonably possible
self-documenting, meaning easy to read and understand, with a clear
structure, helpful names, appropriate types (where applicable) etc etc.

But that code is documenting what is does, not what it should do.
That is the fallacy of self-documenting. It is simply a bogus concept.
If you have the two together then if they match, most likely the program
is written correctly. If you have only the one you can't make the
comparison.

I don't think you should have a line of comment per line of code. I once
worked in a place where they insisted on 1 comment per 5 lines of code.
I was the #1 troublemaker there after they created that rule - I hated
it. It resulted in a lot of bogus comments that added nothing. Its what
you write and where. The problem with the self-documenting crowd is they
don't write anything so you can't follow their assumptions in the
comments.

It should be as sparse as you can get but enough so that each
block/chunk of code can be validated by comparing it with the comment
that describes what you are doing.

My first code was basic on a VIC-20, then assembly on a variety of
different 6502/6510 based machines (C64, C16, Atari...). I didn't bother
much with comments back then. I was writing games and once they are done
you never revisit them so you didn't care too much as long as you got
the job done. I thought it was reasonably obvious what each function did
etc. Ding! I went back some years later and looked at some of my own
code. I had little idea what a lot of it did. I started commenting my
code after that. So when it came time to port a game written for the
6510/6516/6502 to the 68000 (Atari ST) and IBM PC-AT (80286) the
comments came in handy. Sadly the game never saw the light of day for
legal reasons outside of my control. The game was a copy of the
wonderful arcade game "Dingo" written by Ashbury Computers and Graphics
(the team that later became Ultimate Play the Game who wrote for the
Sinclair ZX Spectrum very successfully in the 1980s). A bit of history
for you :-)

Since someone mentioned assemblers and significant whitespace and I'm
rambling about assembly: I don't every remember whitespace being
significant for any of the assemblers I used (650x, 630x, 680x, 8085,
80286, 68000). There was a convention though - you indented to column 8
to write the mnemonics and used the first 6 or 7 chars for labels for
branch/jmp instructions.

>Come on, if you have been in the business for 23 years you know what I
mean.

If you mean, should code be well written, thought about, well formatted,
sensible class/variable names, redesigned if you find a better way, sure
no problem with that.

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting

[Slawomir Nowaczyk]

On Wed, 09 Aug 2006 05:00:20 -0700
"br******@gmail.com" <br******@gmail.comwrote:

#Slawomir Nowaczyk wrote:
#
# I must admit I do not get this "indicate intentions twice" argument,
# even though I heard it a number of times now... It's not that braces
# require more work or more typing or something, after all -- at least
# not if one is using a decent editor.
#>
#Its not the typing, its the fact that when you say the same thing
#twice, there is the potential for them to get out of sync.

Which, in my book, is the *right* thing... if I see a wrongly indented
piece of code, that's a good sign that it needs to be checked. It's
the same principle as in "if documentation and code disagree, both are
probably wrong."

YMMV, of course.

#If the method the compiler uses (braces) and the method the human
#uses (indentation) to determine what the code does don't agree,
#then a reader will be likely to misunderstand what it will actually
#do.

Well, not in my experience. In my experience, such discrepancies
usually only show up in places where something bad happens anyway.

#One of the driving principles behind Python is that, because code
#will be read more often than written, readability is more
#important.

That's exactly my point :)

--
Best wishes,
Slawomir Nowaczyk
( Sl***************@cs.lth.se )

Today advance is so rapid that even the astronauts who set foot on the
moon in 1969 had never seen a digital watch

[Slawomir Nowaczyk]

On Wed, 09 Aug 2006 09:13:21 -0500
sk**@pobox.com wrote:

#>
# >of the driving principles behind Python is that, because code will be
# >read more often than written, readability is more important.
#>
# StephenIn which case, for long functions with multiple levels of
# Stephenindentation Python fails compared to languages that use braces
# Stephenor END or end; etc.
#>
#No. In that case Python makes it more readily apparent that your code is
#too complex. With C, Java, C++, Perl or FORTRAN you just smush everything
#over to the left and pretend it's not. ;-)

Well, one space is sufficient indentations for Python, right? So even
on 80 column screen, you can easily fit about 40 levels of nesting
before it becomes a real problem :D

In other words, it is possible to write bad code in any language. We
should focus on making it easier to write good code, not to make
writing bad code difficult.

--
Best wishes,
Slawomir Nowaczyk
( Sl***************@cs.lth.se )

The nice thing about standards is that there are so
many of them to choose from.

[Carl Banks]

Stephen Kellett wrote:

In message <11**********************@p79g2000cwp.googlegroups .com>,
"br******@gmail.com" <br******@gmail.comwrites

of the driving principles behind Python is that, because code will be
read more often than written, readability is more important.

In which case, for long functions with multiple levels of indentation
Python fails compared to languages that use braces or END or end; etc.

I don't really understand how a closing brace helps here. Care to
explain why it helps you?

(Deeply nested long functions are evil anyways. If you have such a
function then you have bigger problems than minor defects in
readability. :)
Carl Banks

[Rob Wolfe]

Slawomir Nowaczyk wrote:

Really, typing brace after function/if/etc should add newlines and
indent code as required -- automatically. Actually, for me, it is even
*less* typing in C and similar languages... I probably should teach my
Emacs to automatically add newline after colon in Python, just as it
does after a brace in C... As soon as I figure out how to deal with
dictionary literals. Hmmm.

Are you sure? My Emacs already know how to do it with the help
of python-mode and magic function py-newline-and-indent.

emacs-version "21.3.1"
py-version "$Revision: 4.63 $"

Regards,
Rob

[skip]

Slawomir#No. In that case Python makes it more readily apparent
Slawomir#that your code is too complex. With C, Java, C++, Perl or
Slawomir#FORTRAN you just smush everything over to the left and
Slawomir#pretend it's not. ;-)

SlawomirWell, one space is sufficient indentations for Python, right? So even
Slawomiron 80 column screen, you can easily fit about 40 levels of nesting
Slawomirbefore it becomes a real problem :D

Oh, sure. Hence the smiley in my post...

Smileys all around. I'm happy.

Skip

[Carl Banks]

Pierre Barbier de Reuille wrote:

Problem being : grouping by indentation do *not* imply good indentation.

By itself, it doesn't. But with grouping by indentation, bad
indentation no longer results from mere carelessness, which is no small
thing.

Although Python doesn't do this, it is possible to mandate a specific
indent (4 spaces, say), or at least a reasonable consistent indent,
which would indeed all but guarantee good indenting. (I say "all but"
only to account for deliberately misleading code, perhaps using clever
line breaks and comments.)

For example, I had to read a piece of (almost working) code which looked
like that :

if cond1 : stmt1
stmt2
stmt3
if cond2: stmt4
stmt5
elif cond3: stmt6
stmt7
else: stmt8
stmt9
stmt10
stmt11

So you can tell what you want, but this code is valid but impossible to
read and impossible to reindent correctly. So although I personnaly like
Python, I still don't think meaningful indentation is good.

Even if this were legal code (it isn't), it's still more transparent
than some of the C code I've seen.
Carl Banks

[Michiel Sikma]

Op 9-aug-2006, om 16:48 heeft Carl Banks het volgende geschreven:

Even if this were legal code (it isn't), it's still more transparent
than some of the C code I've seen.
Carl Banks

Still kind of too bad that means there won't ever be an International
Obfuscated Python Code Contest.

#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
_-_-_-_
_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_
_-_-_-_
}

:)

Michiel

(source: http://www0.us.ioccc.org/years.html#1988)

[Ed Jensen]

infidel <sa***********@gmail.comwrote:

Where are they-who-hate-us-for-our-whitespace? Are "they" really that
stupid/petty? Are "they" really out there at all? "They" almost sound
like a mythical caste of tasteless heathens that "we" have invented.
It just sounds like so much trivial nitpickery that it's hard to
believe it's as common as we've come to believe.

I like Python, but I do wish it used braces instead, if only because
every editor I'm likely to use supports brace matching, which makes it
easy to (for example) jump to the bottom or top of a block.

[Carl Banks]

Michiel Sikma wrote:

Op 9-aug-2006, om 16:48 heeft Carl Banks het volgende geschreven:

Even if this were legal code (it isn't), it's still more transparent
than some of the C code I've seen.

Carl Banks

Still kind of too bad that means there won't ever be an International
Obfuscated Python Code Contest.

#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
_-_-_-_
_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_
_-_-_-_
}

:)

Michiel

(source: http://www0.us.ioccc.org/years.html#1988)

*yawn* ;)
Carl Banks

[Gerhard Fiedler]

On 2006-08-09 11:10:20, Stephen Kellett wrote:

If you mean, should code be well written, thought about, well formatted,
sensible class/variable names, redesigned if you find a better way, sure
no problem with that.

I mean the code should be written so that as few as possible comments are
necessary to understand it. I don't mean that additional comments are a bad
thing.

Gerhard

[Tim Roberts]

Dennis Lee Bieber <wl*****@ix.netcom.comwrote:

>
I forget what COBOL used, but it had a few fields of its own.

Not in fixed columns. Surprisingly, layout in COBOL was more closely
related to Python, in that indentation was significant, but the number of
characters per indent was up to the programmer.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[H J van Rooyen]

"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote:

| On 8 Aug 2006 04:59:34 -0700, gs*********@gmail.com declaimed the
| following in comp.lang.python:
|
| >
| Some of it may be a reaction from "old-timers" who remember FORTRAN,
| where (if memory serves), code had to start in column 16 and code
| continutations had to be an asterik in column 72 (it's been many years
| since I've done any work in FORTRAN, but you get the idea)
| >
| Comment C in column 1
| (often extended to accept OS JCL markers too)
| Label numeric in 1-5
| Continuation anything in column 6
| (DEC, if using tab indents would take "<tab>&")
| Statement column 7-72
| Sequence/ID column 73-80
|
| I forget what COBOL used, but it had a few fields of its own.

The COBOL I used (NCR Century, Burroughs, some little IBM) was not fussy - the
only thing was that like in assembler, you had to start a lable (that is a
symbolic name for an address) in the first column...

And you *had* to end what Python calls a "suite" with a fullstop - many hours
spent looking for weird bugs..

The breaking of the link between a lable or name and a memory address of
something is what I think most newcomers to Python find horribly confusing...

- Hendrik

[Stephen Kellett]

In message <ma***************************************@python. org>,
sk**@pobox.com writes

>No. In that case Python makes it more readily apparent that your code is
too complex.

If only life and software engineering was that simple. Not every problem
can be reduced to one screenful of code, not in the real world anyway.

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting

[Stephen Kellett]

In message <ma***************************************@python. org>,
Gerhard Fiedler <ge*****@gmail.comwrites

>I mean the code should be written so that as few as possible comments are
necessary to understand it. I don't mean that additional comments are a bad
thing.

Agreed. Concise code is always good.

Just found this on c.l.ruby. Seems kind of relevant.

<QUOTE>
My apologies if someone has posted this already -- I just received it:

http://www.americanscientist.org/tem.../assetid/51982

The Semicolon Wars

Every programmer knows there is one true programming language.
A new one every week
</QUOTE>
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting

[Slawomir Nowaczyk]

On Wed, 09 Aug 2006 07:33:41 -0700
Rob Wolfe <bl****@interia.plwrote:

#Slawomir Nowaczyk wrote:
#>
# Really, typing brace after function/if/etc should add newlines and
# indent code as required -- automatically. Actually, for me, it is even
# *less* typing in C and similar languages... I probably should teach my
# Emacs to automatically add newline after colon in Python, just as it
# does after a brace in C... As soon as I figure out how to deal with
# dictionary literals. Hmmm.
#>
#Are you sure? My Emacs already know how to do it with the help
#of python-mode and magic function py-newline-and-indent.
#>
#emacs-version "21.3.1"
#py-version "$Revision: 4.63 $"

OK, my python-mode.el was older, so I upgraded to 4.75, but it still
doesn't work. Did you mean that after you write

if x==1:

the newline is inserted automatically when you type ":"? That's a
functionality I would like to see, but it doesn't seem to work this
way.

Anyway, I am using python.el most of the time and it doesn't have that
functionality yet.

--
Best wishes,
Slawomir Nowaczyk
( Sl***************@cs.lth.se )

Live in the past and future only.

[Stephen Kellett]

In message <11**********************@b28g2000cwb.googlegroups .com>, Carl
Banks <pa************@gmail.comwrites

>Stephen Kellett wrote:
I don't really understand how a closing brace helps here. Care to
explain why it helps you?

>(Deeply nested long functions are evil anyways. If you have such a

I didn't write deeply nested. I wrote multiple levels of indentation.
They are not the same thing (they can be, but they don't have to be). A
lot of code gets to 3 or 4 levels of indentation quite easily. I
wouldn't call that deeply nested, not by a long shot.

To answer your first question: In C++/Ruby/Pascal you'd have something
like this

function()
{
loop1()
{
blah
blah

loop2()
{
blah

loop3()
{
blah
}

blah
}
}

otherloop()
{
blah
}
}

and in Python that gets to

function()
loop1()
blah
blah

loop2()
blah

loop3()
blah

blah3

otherloop()
blah

I really dislike that the end of loop2 is implicit rather than
explicit. If its implicit you have to look for it. And if blah3 didn't
exist then both loop2 and loop3 would be ending implicitly. This problem
gets worse with longer functions and more indentation. I'm sure some
people are thinking the above is elegant. To me, its clumsy, and here is
why...

Now, the above Python version looks nice, I grant you, but that is
because it is short. I'm talking about long functions which take up some
space. When you come to add loop4, which for arguments sake is after
loop2 but before otherloop() and at the same indentation as loop2, thats
trivial in C/Ruby/etc but in Python I've got to scroll up the screen
find loop2, remembers its indentation go back down and carefully insert
it hoping I've got it right. I don't have do that with C/Ruby etc
because loop2() ends with a brace/end statement so I know its
indentation/end point without having to go and find the start of it
(which is off the screen).

Yes the above example is contrived - so that I could demonstrate what I
wanted to demonstrate. But I've run into these problems with Python code
I've written and when reading code written by others. Its a real
problem, not just one I've cooked up for an argument.

As part of my day job I get to look at a lot of code written by other
people, mainly people I've never met and often people I've never even
traded email with. Strangely, if people have traded email with me, code
that arrives is usually well formatted :-) The amount of code written in
horrible styles is amazing, but if you can't spot the start/end of
loops/conditionals easily and quickly without having to actually read
the code then scanning for the actual code of interest becomes a lot
harder. C/C++ have quite a number of horrible styles (K/R being one)
which can be fixed with a code formatter, but that implicit loop ending
thing with Python I demo above - thats a language feature and nothing I
can do will make that go away.

I'm always thinking maintenance and readability, some time after the
fact. I know that I'll have a reason to come back some time later. Maybe
for a bug fix, a feature improvement or just to lift some code. That is
why stuff like this is important to me. It needs to be as fast,
efficient and error free as possible. And the above doesn't do if for
me.

Now I'm sure some of you will think I'm mad or whatever, but things like
this are important (to me, at least). I don't want to waste my time with
issues like the above. If I'm wasting my time on stuff like this it
can't be that readable can it? If you think the above isn't an issue
we'll just have to agree to disagree.

There some are people on the c.l.ruby newsgroup that love Ruby because
they don't have to type semicolons anymore. Not that its going to change
the world, but its important for them. I think that is one of the least
important things you can think of about Ruby, but there you go.

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting

[Rob Wolfe]

Slawomir Nowaczyk wrote:

On Wed, 09 Aug 2006 07:33:41 -0700
Rob Wolfe <bl****@interia.plwrote:

#Slawomir Nowaczyk wrote:
#>
# Really, typing brace after function/if/etc should add newlines and
# indent code as required -- automatically. Actually, for me, it is even
# *less* typing in C and similar languages... I probably should teach my
# Emacs to automatically add newline after colon in Python, just as it
# does after a brace in C... As soon as I figure out how to deal with
# dictionary literals. Hmmm.
#>
#Are you sure? My Emacs already know how to do it with the help
#of python-mode and magic function py-newline-and-indent.
#>
#emacs-version "21.3.1"
#py-version "$Revision: 4.63 $"

OK, my python-mode.el was older, so I upgraded to 4.75, but it still
doesn't work. Did you mean that after you write

if x==1:

the newline is inserted automatically when you type ":"? That's a

Exactly.

functionality I would like to see, but it doesn't seem to work this
way.

Here is fragment of my python-mode.el:

"""
The \\[indent-for-tab-command] and \\[py-newline-and-indent] keys try
to suggest plausible indentation, based on
the indentation of preceding statements. E.g., assuming
py-indent-offset is 4, after you enter
\tif a 0: \\[py-newline-and-indent]
the cursor will be moved to the position of the `_' (_ is not a
character in the file, it's just used here to indicate the location of
the cursor):
\tif a 0:
\t _
If you then enter `c = d' \\[py-newline-and-indent], the cursor will
move
to
\tif a 0:
\t c = d
\t _
Python-mode cannot know whether that's what you intended, or whether
\tif a 0:
\t c = d
\t_
was your intent. In general, Python-mode either reproduces the
indentation of the (closest code or indenting-comment) preceding
statement, or adds an extra py-indent-offset blanks if the preceding
statement has `:' as its last significant (non-whitespace and non-
comment) character. If the suggested indentation is too much, use
\\[py-electric-backspace] to reduce it.

"""

Regards,
Rob

[gslindstrom]

Carl Banks wrote:

Although Python doesn't do this, it is possible to mandate a specific
indent (4 spaces, say), or at least a reasonable consistent indent <snip>

I like running reindent.py (found in your Python source directory under
Tools/Scripts) which cleans up indentations, trailing whitespace, and
other things. We run our entire source directory through reindent
before we check it into our library. A very nice routine courtesy of
Tim Peters, I believe.

--greg

[Rhamphoryncus]

Stephen Kellett wrote:

function()
loop1()
blah
blah

loop2()
blah

loop3()
blah

blah3

otherloop()
blah

Yes the above example is contrived - so that I could demonstrate what I
wanted to demonstrate. But I've run into these problems with Python code
I've written and when reading code written by others. Its a real
problem, not just one I've cooked up for an argument.

[much snippage]

I actually agree with you here; when indentation goes on longer than a
screen it can become difficult know what that indentation is associated
with. Braces may mitigate it somewhat, but not completely. Some
points to consider:

* Python is inherently shorter than C/C++, so you're less likely to go
over one screen.
* Long functions should usually be refactored anyway and would gain
readability in any language. The threshold here is smaller in python
because your code will do more significant things, vs C where your
screen gets covered with minutiae that you learn to mentally ignore.

Also, I wonder if a more intelligent editor would help here, one that
would visually indicate blocks as such:

function()
| loop1()
| | blah
| | blah
| |
| | loop2()
| | | blah
| | |
| | | loop3()
| | | | blah
| | |
| | | blah3
|
| otherloop()
| | blah

Surely this would eliminate the problem?

[Carl Banks]

gs*********@gmail.com wrote:

Carl Banks wrote:

Although Python doesn't do this, it is possible to mandate a specific
indent (4 spaces, say), or at least a reasonable consistent indent <snip>

I like running reindent.py (found in your Python source directory under
Tools/Scripts) which cleans up indentations, trailing whitespace, and
other things. We run our entire source directory through reindent
before we check it into our library. A very nice routine courtesy of
Tim Peters, I believe.

The very fact the code reindenters exist should tell you that fixed
indent is superior. :)
Carl Banks

[Carl Banks]

Stephen Kellett wrote:

I really dislike that the end of loop2 is implicit rather than
explicit.

So you can't see at a glance how many blocks were closed. That's fair.
Add a little chalk mark to the against column.

C/C++ have quite a number of horrible styles (K/R being one)

Oddly, I never used to use K & R until I was a longtime Python
programmer. Then I wanted to get those redundant braces as far out of
the way as reasonable; hence K & R. Maybe someday I'll take up a
LISP-like style and put the closing brace on the last line of the
block. (No, I won't.)
Carl Banks