> [Thomas Kofler]
> But: I dislike the fact that blocks of statements are not enclosed by
> balanced parentheses (or something like that), and that statements are
> terminated by a newline.
> Awk did that better, IMO, because no particular formating of the code
> is imposed.
> Any chance that that will be changed in the future?
g> Sorry for not responding earlier. I did see your message but hoped
g> that someone else would explain my point of view to you :-).
You will get no help from me on this one :)
g> Basically I believe that using indentation for grouping is extremely
g> elegant and contributes a lot to the clarity of the average Python
g> program.
When it comes to reading the program I have to agree with you. It
makes for a very clean and readable program. Often people refer to
languages like perl and APL as beign write-only languages, while not
quite to the same extreme, I sometimes refer to Python as a read-only
language.
I have no problem with the language forcing a particular style on its
users, but I think there are other ways that this could be
accomplished. My main complaint is that Python cannot be
automatically reformatted. When I am in the middle of a Python
hacking session, (cut-n-paste programming) I don't want to have to
think about how the code is going to change simply because I removed
or added some white space. I suppose that if I only programmed in
Python I would get used to its ways... but I don't, and I haven't.
g> Some arguments for it:
g> - Since there are no begin/end brackets there cannot be a disagreement
g> between grouping perceived by the parser and the human reader. I
g> remember long ago seeing a C fragment like this:
g> if (x <= y)
g> x++;
g> y--;
g> z++;
g> and staring a long time at it wondering why y was being decremented
g> even for x > y... (And I wasn't a C newbie then either.)
The problem with these statements is easily detected simply by
reformating the function containing them. Even better would be to
have the parser give a 'style error'
(style error: line 10, attempt to mix checks and stripes)
In other words, make the indentation information redundant and have
the parser verify that it is consistant with the nesting level.
Correcting source code with style errors would be as simple as running
the code through a pretty-printer program or hitting M-Q in emacs.
This is somthing that is impossible in Python today.
g> - Since there are no begin/end brackets there can be no conflicting
g> coding styles. In C there are loads of different ways to place the
g> braces (including the choice whether to place braces around single
g> statements in certain cases, for consistency). If you're used to
g> reading (and writing) code that uses one style, you will feel at least
g> slightly uneasy when reading (or being required to write) another
g> style.
Again, the parser can enforce the one true coding style and shower the
deviant programmer with numerous messages whenever they go astray. In
principle, however, I do agree that there is a certain amount of
comfort associated with working with code that looks like your code.
But this almost sounds like an argument that could be used to justify
having the parser enforce the one true naming convention for variables
and functions.
g> - Many coding styles place begin/end brackets on a line by themself.
g> This makes programs considerably longer and wastes valuable screen
g> space, making it harder to get a good overview over a program.
g> Ideally, a function should fit on one basic tty screen (say, 20
g> lines). 20 lines of Python are worth a LOT more than 20 lines of C.
g> This is not solely due to the lack of begin/end brackets (the lack of
g> declarations also helps, and the powerful operations of course), but
g> it certainly helps!
This one is a little tougher to address. So I will simply say that a
little vertical white space never hurt anyone. I happen to like the
syntax of Ada w.r.t the way it handles code blocks. All compound
statements implicitly open a block that must be closed with an end
statement. This scheme only adds a one extra line, not two as in C or
Pascal.
--Don
(If I'm not already on Guido's shit list, I'm sure he just added me to it.)
______ ______
\_\_\_\ /#/#/#/
\_\_\_\ ______
\_\_\_V#/#/#/ Donald Beaudry don@vicorp.com
\_\_/#/#/#/ V. I. Corporation uunet!vicorp!don
\_/#/#/#/ 47 Pleasant Street PHONE: (413) 586-4144
V#/#/#/ Northampton, MA 01060 FAX: (413) 586-3805