Larry Wall's comment on python...

[Magnus Lyckå]

laotseu wrote:
> Rod Stephenson wrote:
> 
>> Slashdot has a list of questions posed to Larry Wall (perl). When
>> asked his thoughts on other scripting languages, he makes the
>> following observation about python
>>
>> "Python is cool to look at small bits of, but I think the "outline"
>> syntax breaks down with larger chunks of code. I'm with Aristotle on
>> the structure of discourse--a story should have a beginning, and
>> middle, and an end. So should blocks"

Don Knuth said:
"We will perhaps eventually be writing only small modules
which are identified by name as they are used to build
larger ones, so that devices like indentation, rather than
delimiters, might become feasible for expressing local
structure in the source language."
See http://www.thinkware.se/cgi-bin/thinki.cgi/PythonQuotes

Stephen Edwards said:
Python: Perl designed by a sane man.
http://www.cs.columbia.edu/~sedwards/classes/2002/w4115/scripting.pdf

Of course there is an end for every Python block. The
Zen thing to consider is the old: "What is the sound of
one hand clapping?" Consider that, and return when you
are enlightened. ;)

My personal experience from many years of coding C++ etc
with curlies and Python without, is that I tend to get
lost a lot more in my C++ code than in my Python code.
Not to mention the code of others... I've certainly had
a number of debugging sessions where I had to help some
mediocre C++ coder who couldn't match his own braces...
The problem is usually that the blocks get to big... The
fact that you can get away with incorrect indentation in
the brace-languages makes it worse.

Most modern editors have tools like indentation guides and
folding that can make it easier to see block structures.

Was it one of Beethoven's symphonies that ended so abruptly
that the audience didn't understand when to applaud? It was
considered a big failure at it's time, and it's considered
one of the best works of a genious today...

>> I'm not quite sure what he's trying to get at here - I guess that for
>> a long heavily indented chunk of code, you could lose track of the
>> overall structure, but I don't write code this way.
>>
>> Any comments?
> 
> 
> def fun(args):
> #BEGIN
>     if ceci or cela:
>     #BEGIN
>         do_this(with_that)
>         [snip a lot of code]
>     #END
> #END

I would recommend against such a coding style.

First of all, if it's difficult to understand the code
(even after the first 10 minutes of Python exposure)
you probably have a bad structure in your code. Too
big blocks, or too much nesting in the structure. The
solution there is refactoring, not comments.

Secondly, you are adding something redundant and foreign
to your code. Getting used to how Python actaully looks
is a better idea than trying to make it look like Pascal.

Thirdly you are creating a maintenace problaem. The main
problem with all comments (except that they often don't
get written) is that they tend to get out of sync with
the code. No syntax checks or test script will detect if
your #END markers are incorrect. If the code is bad enough
to warrant #END markers, it will be easy to write them
incorrectly, and even easier to make mistakes when you
change your code, adding or removing a loop or an if-
statement in the middle of the structure.

If you still feel that you want an explicit end marker to
your blocks, do it like this.

  * Forget about #BEGIN, if you are unable to see where the
    Python blocks begin, you might as well give up.

  * Please forget about the ugly capitals.

  * Add some meaningful information to the end marker so that
    you see which block you are ending.

  * Make sure that you have a program that will check / generate
    the end markers.

It could look like this:

def fun(args):
     if ceci or cela:
         do_this(with_that)
         [snip a lot of code]
     #end: if ceci or cela
#end: fun(args)

It shouldn't be so difficult to write a python script that
will remove all lines beginning with #end: and then regenerate
them correctly for all blocks. (Not that I find it worth
while...)

These kinds of scripts are good to run as pre-checkin triggers
if your develpment environment supports that kind of routines.