That is one reason I dropped the whole topic the last time out - I wasn't
so sure about even what *I* though of my own ideas: Some of the problems
and solutions were in opposition to each other. The other reason has
been demonstrated again in this thread: questions of style bring out
lots of opinions, and twenty different ideas, mostly incompatable, on
how to change things. I suspect a lot of other folks out there would
rank the various notions roughly as I have:
My ( insert your name here ! ) syntax changes.
The current syntax rules.
All of those other "ugly" syntax suggestions.
Since the current syntax is almost everyone's second choice, even
without Guido vote, I think it would still win! <0.3 smiley>
But here's my classification of the problems that people want to fix.
1) style & aesthetic objections.
A lot can be said about this, but I won't say it now.
For now, we'll define it as a non-problem. ( i.e.
"Let Python be Python!" :-)
2) single line code limitations for interactive entry & lambda functions:
When scrolling lines with gnu-readline, or when cutting and
pasting code fragments, it is nice to be able to get a whole
command on one line. lambda's are limited to one line, which
also means that they can't use 'if' or other compound statements.
3) generated code strings:
This is an important problem, but it has an easy solution.
Generate code strings with an INDENT/DEDENT token string,
and run it thru a filter that keeps track of the proper
tab level and expands the code. Since my definition, this
code is being generated by some process before it is compiled
and/or eval/exec-ed, there is really no problem with adding
one more processing step. It *would* be nice to have a standard
ascii representation for INDENT/DEDENT and some standard filters,
though.
4) extra redundancy:
This is a very interesting proposal - but maybe not for Python.
It has to be non-optional to be useful, and except for the
"required #END comment" with switch/pragma, it breaks all
existing code.
5) cutting and pasting code blocks.
With a good editor, this should not be a problem, but not
everyone has a good editor available. Some tools ( text widgets
and Mac TEXTEDIT, have built in editing operations that don't
respect white space. A related problem is how to cut and past
from a interactive window and get rid of the ">>>" + '...'
leading chars! )
6) filtering code thru things that don't respect whitespace:
Some people have mentioned problems with macro processors.
I would like to embed Python code in a html or other
structured text document and be able to both extract
executable code and documentation separately, or
"pretty print" the code with keywords in itallic,
comments in another typeface, and perhaps other emphasis.
( Note that in Knuth's WEB system, the Pascal code
extracted and passed to the compiler was compressed
together with the "interesting" commentary stripped
and replaced with short line-number comments. )
#1 I have called a non-problem.
#3 has a solution.
#4, being a required, rather than an optional syntax change is too
extreme for me. Plus, it does nothing to solve the other problems.
#2 is irritating, but I can live with it.
#5 and #6 are real, difficult and related problems.
One could argue that the problem is with the other tools (broken
editors) and *NOT* with Python, but that doesn't help much.
But I'm not sure that any of the proposed ideas really go very
far in solving those problems in general - only a few restricted
cases. I would almost rather see a more generalized macro facility,
however, I know that would probably introduce another set of problems.
I would urge Guido to NOT let himself be stampeded into a "solution"
quite yet! I didn't speak up sooner, because Guido has usually been
rather conservative, and has asked for some "proof-of-concept" before
adding or changing the base language. ( "lambda" is the only thing
in recent history that was "broken" when it was introduced, and there
was a simple compatible fix introduced. I attribute that to the fact
that Guido isn't much of a Lisp fan, so he didn't realize how severely
the scope problem restricted it's use. ) But I'm concerned that he
appears to be wavering in that resolve!
What I **DON'T** want:
A new keyword(s). A diglyph is safer - we don't have to
search thru our code for "begin","end", etc. Plus, since
Python already uses ":" to indicate the start of a block,
a non-alphabetic character of character pair would (IMHO)
fit better. And unless you can print them in a differnt
typeface, begin/end blend into the background "noise" too much.
An ambiguous character or diglyph. I don't mean ambiguous
to the parser, I mean ambiguous to a reader. Parends
or brackets, even when paired in ":{" "};" or ":(" ");"
can be confusing. ":<" and ">;" are unambiguous. ( So
are many others, but that's the best looking pair I can
think of. )
Command line switches to switch between old and new style.
( I would rather see a general import filter hook, and if
there is a way to do it, an interactive input filter hook.
This would help with the structured text problem, which none
of the other proposals address. )
BTW: whitespace *IS* significant in almost all computer languages.
The significance rules vary. In Fortran, all newlines are significant.
Spaces and tabs are significant in some cases. But in others, like
the infamous "DO J = 1. 10" bug, they are not. I consider the
C bugs introduces by misleading indentation as a similar class.
People always point out that if you use the right editor, then it
becomes a non-problem. But the same argument applies for all of
these Python "problems". All in all, I prefer the Python problems
to the C problems!
PS: I *DO* have more to say about coroutines someday soon!
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics