RE: [RFC] Draft Proposal for New Python Syntax

John Grayson (johng@astro.NoSubdomain.NoDomain)
Fri, 27 May 1994 13:23:24 GMT

In article <>, (Michael McLay) writes:
|> The draft proposal for a new Python Syntax has a number of flawed
|> arguments and personal preference statements that should not be
===== Deleted
|> And thanks to Guido for resisting the temptation to give into the
|> temptation of adding everybody's pet requirement to the language.
|> Michael

I have to agree with Michael. While changes to Python syntax to support
extensions or correct day-one-errors should be argued vigorously, this
proposal is based more on aesthetics than a need to improve Python.

I've been exposed to Python for about 6 months now and and it has been my
experience that problems caused by faulty indentation are INSIGNIFICANT
compared to errors caused by typos or abused functions. The reason I use
Python is to take advantage of its power; part of that power comes from
dictionaries, so I find any proposal which proposes kludges to core Python
functionality to be focussed in the wrong area.

If C or C++ are seen as ideal models for syntax, then why not use them?
To make Python C-compliant is not necessary or desirable.

Additionally, the required changes to Python programs to account for
format and semantic changes will be expensive, tedious and may damage
reliablity of existing programs. Does anyone suppose that it would be
possible to get C syntax changed with extensive code change requirements?
For example I've always found conditional expressions to be ugly - why
don't I start a campaign to change it:

z = (a > b)?a:b ===>> z = (a > b)<T>a<F>b

See how it helps novices and it looks better!! :-)


Python code is not particularly hard to debug and it has value in having
simple, consise code deliver extensive functionality. There are things
better done in Python than C (from an ease of development perspective).
Remember that ALL translators/interpreters are merely tools. It is the
skill of the user rather than the language itself that determines how
effective the end-product will be.

Let's get back to writing code rather than talking about it...

:-j ohn

John Grayson                "Positive air infiltration"                John Grayson, 1984