"Stephen Kellett" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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
--
http://mail.python.org/mailman/listinfo/python-list
