Let us be concrete:
1) No, it is not a question of liking the syntax or not. I can live
with the syntax as it is. I can live with Donald's syntax, and with
other conceivable syntaces. I do not care as long as I am writing
"small" Python programs. In my opinion, Python can be used for more
than writing "small" programs.
2) I am embedding Python into our application framework ET++. The
latter is written in C++. The goal is to script ET++ applications using
Python. One particular kind of usage is to use Python for
spreadsheet-like applications. Note: Not one spreadsheet, but a series
of spreadsheet-like apps. The basic infrastructure, however, is more
general. Currently, we have a Tcl embedding. Tcl has its problems, and
I want to get rid of it. I would like to substitute Tcl for Python as a
general scripting device.
The binding between ET++ and Python has a layer in Python that allows
to provide a nice interface to the underlying engine. Some of the code
of this layer will be generated. I also want/need (whatever you
prefer) to use macro processors for that purpose.
BTW: I do not see macro processors as an old-fashioned tool for
constructing software. If anybody is interested in this question, we
can discuss that further.
I cannot use m4 (or even cpp) for that purpose. Well, I could
invest some time to devise a macro processor working for
the Python syntax. Work-around 1.
For code generation, the current syntax does not pose a real problem.
It is simply annoying to carry the current required indentation level
all around the computations.
3) To recover lost indentation, there are some work-arounds. Solving
that problem leads to solutions like #end and an appropriate script,
for instance. Work-around 2.
4) For entering Python code in, say, a spreadsheet-like application, I
can use some code written by Guido that reformats the entered text. So
far, so fine. Now, I have to provide a way to tell the user in a
user-friendly way where, say, a syntax error occured. This means that I
have to write code that allows me that (Note: Python has nothing like a
line-directive). I have to take care all the time that preprocessing
and postprocessing code takes all that into account. Work-around 3 and
4. (You might also think of offering a debugging facility: The problems
never end...)
Some people stated in other postings that the burden of the proof is
due to those who want a syntax change. In my eyes, there is not much
to prove. It is rather a question whether what people want to do, and
how they want to solve issues like those described above if they need
to. The issue is a "political" one: Sacrifice a nice feature (the
current syntax) and impose some migration costs versus a Python that
scales.
----------------------------------------------------------
Thomas Kofler |Email: kofler@ubilab.ubs.ch
Union Bank of Switzerland |Tel: +41-1-236 4567
Bahnhofstr. 45 |Fax: +41-1-236 4671
CH-8021 Zurich, Switzerland |
----------------------------------------------------------