Hear, hear! Please don't pollute the language with this cruft. Keep
Python Beautiful (tm)! (or the Texas equivalent slogan, "Don't Mess With
Python!")
> Thomas Kofler writes:
>
> > The new syntax makes programs immune against semantical changes due
> > to different formating.
>
> The existing syntax is currently immune to semantic changes due to
> missing or misplaced braces. A bug is a bug.
In my humble experience, Python's approach wins much more often than it
loses on this count. In C, I do from time to time bracket a block of
code differently than I intended and differently than I indented it. I
have never written code that was bracketed correctly but indented wrong.
I can't see how that would ever happen except to beginning programmers,
and they really, really need to learn to indent correctly.
> > In particular, the new syntax is expected to and will:
> > 1) ease the editing of Python code in practice
Yes, python's syntax is a tad harder for auto-indenting editors to
handle. The editor I use has built-in C editing, but isn't readily
configurable to handle python. The solution isn't to change the
language, though, but to {fix the/get a better/write a new} editor.
> > 2) ease the use of macro processors and code generators
IMHO, an interpreted language that needs a macro preprocessor for normal
use probably has something *really* wrong with it. Compilers get a
little more leeway here due to conditional compilation and such. Even
in those cases, it's probably better to put a minimal version in the
language itself rather than as a preprocesor.
> Why do you believe the new syntax make code generation easier? Please
> supply some evidence.
Some code was posted to the old mailing list last time this came up,
demonstrating how easy it was to generate python code right now. What's
more, you get readable, nicely indented code generated rather than a
tangle of run-together code and brackets.
> > # dangling else resolved as usual: it belongs to the most
> > # recent 'if', 'for', or 'while', etc.
>
> So I have to manually parse the source code to find the most recent
> if, for, or while? This is an advantage?
Definately not. Python finally solved once and for all the dangling else
problem.
> Like an indented outline of a book, the existing syntax assists the
> visual parsing of the code. Your syntax make writing parsers easier and
> allow four lines of code to be compressed to one line. Which syntax
> will be of greater value when someone takes over the task of
> maintaining this code?
People often use the case of someone else maintaining code as an example
in this kind of discussion. I've always felt that it was a bit too far
removed from the programmer's needs to be an effective argument. I take
the stance that things that make a future maintainer's work easier are
all well and good, but that they're even more important for how much
easier they make MY work!
In my experience, maintaining my own code is a bit harder (all things
such as quality of comments, etc being equal) than maintaining someone
else's code that I haven't seen before. This is simply because I may
bring false assumptions of correctness and misremembered details to my
own code, while I get to look at someone else's code with a fresh eye.
This is a corollary of the familiar "I couldn't see a thing wrong with
the code, but when I showed it to someone else it was blindingly obvious
to them" situation.
Things like Python's clean syntax also make it easier to write new code.
If I'm flipping around looking at other code and then flip back to
code-in-progress, anything that helps be "reacquire the mental state"
(for lack of a better description) of that code more quickly makes me
more productive. This is why it makes sense to write pretty code to
begin with, rather than writing ugly code and then running it through a
prettyprinter.
[So my theory is: don't appeal to a programmer's concern for future
maintainers, appeal to their self-interest and the here-and-now.
You'll make it easier for future maintainers as a byproduct :-)]
> And thanks to Guido for resisting the temptation to give into the
> temptation of adding everybody's pet requirement to the language.
As a final comment, let me suggest that if we absolutely have to have
explicit block delimitation that it be a) optional and b) with the
tokens "Begin_a_Block_of_Python_Code" and "End_a_Block_of_Python_Code",
with exact case required. It would serve the pro-explicit-bracketing
people right to have to type that all day long :-). More likely they'd
just give up and go back to C, and then we can take explicit bracketing
out of Python again.
Now-how-about-a-discussion-on-how-to-improve-the-
readability-of-these-closing-"something-ly-y'rs"
-comments-ly y'rs - Ty
-- Ty Sarna "It pays to be obvious, especially if you have a tsarna@endicor.com reputation for subtlety" -- Salvor Hardin