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.

[H J van Rooyen]

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

| On 8 Aug 2006 04:59:34 -0700, gs*********@gma il.com declaimed the
| following in comp.lang.pytho n:
|
| >
| 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************ *************** ************@py thon.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************ *************** ************@py thon.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************ **********@b28g 2000cwb.googleg roups.com>, Carl
Banks <pa************ @gmail.comwrite s

>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*********@gma il.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