No doubt here... Python is great the way it is... but it could be better.
m> Despite my better judgement :-), here's my $0.03 worth too. Some of
m> this has already been pointed out by others.
m>
m> I've followed the syntax debate with interest, and I must say-- I just
m> don't get it. I have yet to hear a compelling reason to change Python's
m> elegent indentation-based syntax model.
The most compelling reason that I have heard is that, as-is, you
cannot reconstruct a properly indented program from an improperly
indented one. I agree that Python's indentation-based syntax model is
not only elegent, but is also very useful. That is why I did not
propose to eliminate. I would like to simply agument it in such a way
as to eliminiate its only major flaw.
m> 1) Cut-and-paste between editor windows doesn't work.
m> Say what? This doesn't work with C code either, unless you're willing
m> to let your indentation levels degenerate to the point of unreadability.
m> I always need to go fix the indentation levels when pasting C code in a
m> source file; the fact that Python forces this is a Good Thing.
It is quite a bit easier to fix up the indentation of a C program than
it is to fix up the indentation of a Python. Given a good set of
"style-rules" and a messed up C program, there is only one way to fix
up the indentation. Given Python's current syntax and a messed up
Python program, there are many ways to fix it up... and each means
somthing different. To properly re-indent a Python program you must
read the code and figure out which of the many possible combinations
is the right one.
m> 5) I don't like to be forced to code one way.
m> This is an unresolvable religious issue. All I can suggest is that
m> EVERY language imposes some form of syntax style, whether you
m> realize it or not. In C, we have to type all those '{' and '}',
m> just to make the compiler happy. In Pascal, it's BEGIN/END; in
m> Lisp, it's parentesis hell; and in COBOL, it's just plain hell :-).
m> What people really object to is that Python imposes a _different_
m> syntax than they're used to (which is not the same as deciding it's
m> wrong). Many people have testified to the value of Python's syntax
m> here, and I won't repeat their remarks. The only point I'd make is
m> that Python syntax FORCES all programs to look alike, which makes
m> readability, and therefore maintenance, much easier. After
m> maintaining C code for nearly a decade, I can only suggest that
m> forced similarity of coding styles is a Very Good Thing...
I don't mind being forced to code one way. Most companies have some
form of style guide, for whatever language they are using, that
suggests how a program should look. For most languages this
necessary, with Python it is not, nor would I want it to be.
m> But frankly, this excuse for changing the syntax is the most bothersome.
m> It would be ironic if a language feature which made it superior, also
m> inhibited its acceptance because it made it different. If we, as
m> engineers, aren't able to accept and adopt new ideas, who will be?
m> The tendancy of engineers to be overly-conservative when it comes to
m> things they're not used to, is disturbing [I have this nightmare where
m> I wake up 100 years from now, and have to get a job as a Fortran-77
m> coder :-)]
We both seem to agree that Python has this feature that makes it
superior. But, what exactly is this feature? I think that the
feature we are talking about is the required indentation/formatting
that Python's syntax enforces. You seem to identifying this feature
as the lack of an 'end' statement.
Python already has a 'begin' statement... it is written as a colon.
The 'begin' is interpreted relative to its position within the code,
that is, move the code, the 'begin' moves with it. But the current
version of the 'end', the DEDENT token, is an absolute value, and is
not relative to its context, move the code and the DEDENT does not
know that it was moved. This adds an element of asymmety to the
language that I feel should be removed.
m> So my advice to those trying to tamper with the syntax-- try the current
m> syntax for awhile, with an open mind. You'll probably wind up wondering
m> why you wanted to make Python look like C. And my advice to Guido-- don't
m> change the language unless someone comes up with a VERY good reason, as you
m> suggested. Alot of us like it as is.
What makes you think that those who are "trying to tamper with the
syntax" have not used the current syntax? Do you really believe that
the current syntax is so good that no one who has used it would ever
propose to change it? I have written quite a bit of Python code over
the past year or so. I will admit that as it stands it is very easy
to read Python code. But I find it annoyingly difficult to edit.
Also, I don't see how you can say that my proposal is an attempt to
make Python look like C, Ada maybe, but even that is stretching it a
bit. I do vaguely remember that someone had submitted, and
subsequently withdrawn, a proposal which essentially amounted to
changing Python to C, but this is not what I am proposing.
m> The only way to make progress in a field like this is to try new
m> things.
Well I am glad to see that you have an open mind.
--Don
______ ______
\_\_\_\ /#/#/#/
\_\_\_\ ______
\_\_\_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