do people really complain about significant whitespace?

[Tim Roberts]

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.

 

[H J van Rooyen]

| On 8 Aug 2006 04:59:34 -0700, (e-mail address removed) 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]

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]

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/template/AssetDetail/assetid/51982

The Semicolon Wars

Every programmer knows there is one true programming language.
A new one every week
</QUOTE>

 

[Stephen Kellett]

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

 

[Slawomir Nowaczyk]

On Wed, 09 Aug 2006 07:33:41 -0700

#> 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
( (e-mail address removed) )

Live in the past and future only.

 

[Rob Wolfe]

On Wed, 09 Aug 2006 07:33:41 -0700

#> 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]

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]

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]

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]

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

 

[Slawomir Nowaczyk]

On Thu, 10 Aug 2006 04:01:51 -0700

#> > if x==1:
#> >
#> > the newline is inserted automatically when you type ":"? That's a
#>
#> Exactly.

Really? The newline? I know it *indents* automatically. But it
definitely doesn't insert newline when I try it.

I even downloaded revision 4.63 and I really do not see any code for
doing that. py-electric-colon only seems to dedent code.

#> > functionality I would like to see, but it doesn't seem to work
#> > this way.
#>
#> Here is fragment of my python-mode.el:

Please note that this comment doesn't say anything about automatically
inserting newlines, only about indenting (actually, dedenting) as
needed.

Anyway, this is probably becoming off-topic here.

--
Best wishes,
Slawomir Nowaczyk
( (e-mail address removed) )

Cursor: What you become when your computer crashes.

 

[Gerhard Fiedler]

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

function()
{
loop1()
{
[...]
}
}

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

Since in the above languages indentation is optional but you still use it
(and even may use a program that provides the correct indentation if the
coder didn't do it), what prevents you from adding optional end-markers in
Python? They are not required, but they are not forbidden either, very
similar to the indenting in the above languages. Something like this:

function()
loop1()
blah
blah

loop2()
blah

loop3()
blah
#end loop3()

blah3
#end loop2()
#end loop1()

otherloop()
blah
#end otherloop()
#end function()

Of course, few people will write like this, but it probably is easier to
write a Python code formatter that adds them than it is to write a C code
formatter that adds proper indentation and provides your preferred
placement of braces.

Gerhard

 

[Terry Reedy]

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

Much nicer, IMHO ;-).

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.

So add one of those judicious, informative comments that some have written
about in this thread ;-)
# end loop2
where 'loop2' would typically be something like 'i loop'. If blah3 didn't
exist, you could add
# end loop3
*above* the end loop2 comment.

I personally found matching far-apart well-indented braces visually
something of a nuisance too, so I sometimes did much the same in C:
} /* end i loop */

This problem gets worse with longer functions and more indentation.

And devoting lines to braces, including those that are visually interfering
(such as those for loop3) expands blocks and makes it more likely that
blocks will span screens. This makes the problem worse.

I'm sure some people are thinking the above is elegant.

Yes, allowing programmers to add explict end-suite markers only where
needed is, to me, more elegant that forcing redundant begin-suite markers
and often unneeded end-markers.

Terry Jan Reedy

 

[Gerhard Fiedler]

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

http://www.americanscientist.org/template/AssetDetail/assetid/51982

The Semicolon Wars

Good reading Thanks.

Gerhard

 

[Bruno Desthuilliers]

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.

<nitpicking>
Well, one can argue that since Python grammar defines that a code block
ends with the first following non-blank line that one indentation level
less, it's perfectly explicit !-)
</nitpicking>

But practically speaking :

If its implicit you have to look for it.

Indeed. And yes, I agree that it's not that good wrt/ readability for
any complex or long block.

OTOH, nothing prevents you to add a "# end <block>" comment where
appropriate - FWIW, I used to do it in C after the closing brace for any
lengthy block (and code blocks tend to be longer in C than in Python).

 

[Georg Brandl]

function()
loop1()
blah
blah

loop2()
blah

loop3()
blah
#end loop3()

blah3
#end loop2()
#end loop1()

otherloop()
blah
#end otherloop()
#end function()

Of course, few people will write like this, but it probably is easier to
write a Python code formatter that adds them than it is to write a C code
formatter that adds proper indentation and provides your preferred
placement of braces.

It's already there: Tools/scripts/pindent.py.

Georg

 

[Stephen Kellett]

Good reading Thanks.

Found something else relevant to this thread. The Pliant language.
Appears to use whitespace indentation for grouping.

http://fullpliant.org/pliant/language/parser/default_syntax.html

Stephen