Very Bad! IMHO, the utility of a programming language is inversely
proportional to the number of special-cases it imposes. Right now, Python's
struck a balance between utility and simplicity, that makes it suprisingly
easy to use, and lends itself to rapid program development. Changes like
this would make Python harder to learn, code, and read. I commend Guido for
resisting change as a rule; Python's great the way it is.
> I'd like to hear what people think about this matter (except Tim P and
> Steve M -- you are already in the top three :-).
Despite my better judgement :-), here's my $0.03 worth too. Some of
this has already been pointed out by others.
I've followed the syntax debate with interest, and I must say-- I just
don't get it. I have yet to hear a compelling reason to change Python's
elegent indentation-based syntax model.
And coming up with a good REASON (as Guido suggested) must be the initial
step here, NOT a working implementation. Engineers have this annoying
habit of changing things without clear justifications. This is how we got
the current bloated C++ and Fortran-90 messes [further details deliberately
withheld :-)]. I'd hate to see Python go the same way.
So, let's look at REASONS. IMHO, the most prominent reasons I've seen
just don't hold water (forgive me if I've omitted or misinterpreted;
responses are encouraged):
1) Cut-and-paste between editor windows doesn't work.
Say what? This doesn't work with C code either, unless you're willing
to let your indentation levels degenerate to the point of unreadability.
I always need to go fix the indentation levels when pasting C code in a
source file; the fact that Python forces this is a Good Thing.
2) You can't have a simple text widget for user-entry of Python code.
Again, this seems a non-issue. If your users are expected to be smart
enough to type in Python language code directly, surely they must be smart
enough to handle indenting nested blocks too! Further, if your users are
not expected to know how to enter code, it's not clear to me that a blank
text widget/box is a satisfactory user-friendly input device; either you
already have smart users, or you should provide different input mechanisms
than a simple text widget. Either way, Python's syntax doesn't hurt. And
if you're trying to get by with a single-line text entry box, what's so
hard about using a multi-line text box instead? (the utility of making users
type compound statements on a single line seems dubious).
3) It's hard to use Python in some editors.
Again-- what? All I've really needed an editor to do is to auto-indent
each line, and map tabs to blanks (or equivalent functionality). If you
require more (like auto-balancing blocks, etc.), you may be stuck in a
"do-this-like-C" frame-of-mind, which doesn't transfer to Python. Now,
I'm not an editor power-user-- every platform I've worked on has an
editor that can auto-indent, and map tab's to N blanks, and that's been
enough for me; if you have other requirements, you can either use Guido's
delimeter-to-indentation filter on your code, or rethink the need for the
things you're asking your editor to do. By all means, if you have an
absolutely-essential editor feature which is impossible to do for Python,
let's hear about it, so we can have a _real_ discussion. But since there's
already an emacs interface for Python (emacs is, arguably, a worst-case limit
for editor complexity...), I have doubts about the justifications here.
4) It's hard to automatically generate Python code.
Huh? It's not any harder to insert tabs or blanks, than it is to insert
explicit block-delimeter tokens or keywords! All you need is a global
nesting/indentation counter. Trivial. Each language has it's syntax
isiosynchrasies which you need to handle in a code-generator (I know--
I've generated code for C, Prolog, Fortran, and Python). Just because
Python's syntax is different doesn't mean it's any harder. And Guido's
already written a utility to filter non-indented code to indented code.
What more could you possibly need here? If you _must_ generate code with
explicit block markers, just run it through Guido's filter before passing
it to Python. Simple.
5) I don't like to be forced to code one way.
This is an unresolvable religious issue. All I can suggest is that EVERY
language imposes some form of syntax style, whether you realize it or not.
In C, we have to type all those '{' and '}', just to make the compiler happy.
In Pascal, it's BEGIN/END; in Lisp, it's parentesis hell; and in COBOL, it's
just plain hell :-). What people really object to is that Python imposes a
_different_ syntax than they're used to (which is not the same as deciding
it's wrong). Many people have testified to the value of Python's syntax
here, and I won't repeat their remarks. The only point I'd make is that
Python syntax FORCES all programs to look alike, which makes readability,
and therefore maintenance, much easier. After maintaining C code for nearly
a decade, I can only suggest that forced similarity of coding styles is
a Very Good Thing...
6) I just don't like it.
Everyone's entitled to his/her opinion. If you don't like the language as
is, I'd encourage you to try it first. If you still don't like it, don't
use it; but please, don't try to enforce your opinions on those of us that
like the language as is. If you have a real, CONCRETE, and justifiable
reasons for changing the language, I'd be among those most pleased to hear
it.
But frankly, this excuse for changing the syntax is the most bothersome.
It would be ironic if a language feature which made it superior, also
inhibited its acceptance because it made it different. If we, as
engineers, aren't able to accept and adopt new ideas, who will be?
The tendancy of engineers to be overly-conservative when it comes to
things they're not used to, is disturbing [I have this nightmare where
I wake up 100 years from now, and have to get a job as a Fortran-77
coder :-)]
Guido faces something of a catch-22 here: if he makes the language look
like C, he may ruin it; if he doesn't, he may alienate some conservative
C programmers. Surely, it's better to appease those interested in
advancing a new language as is, rather than those seeking to propogate
existing, status-quo technology. If not, we might as well all find a
good C interpreter...
Anyhow,
What I suspect this all boils down to is this: C programmers initially balk
at the idea of indentation-based syntax, because it's _different_. Some of
them have gone so far as to try to change Python to fit their C habits.
I've seen this pattern among almost all C/C++ hackers I've introduced Python
to-- they're puzzled at first, but once they've used Python, they're hooked.
It's just plain simpler to write AND read, which is a key quality in rapid
development languages.
I confess that I had about the same initial reaction to Python myself
(what?...indentation syntax?...they never taught us that in school...).
But it only took using Python once to prove the value of the syntax model.
So my advice to those trying to tamper with the syntax-- try the current
syntax for awhile, with an open mind. You'll probably wind up wondering
why you wanted to make Python look like C. And my advice to Guido-- don't
change the language unless someone comes up with a VERY good reason, as you
suggested. Alot of us like it as is.
The only way to make progress in a field like this is to try new things.
If it weren't for innovation, we'd all be using Fortran-77 well into the next
century (which is not to say we won't, but that's a whole seperate thing :-).
Mark L.