Re: [RFC] Draft Proposal for New Python Syntax
Tue, 24 May 94 17:21:38 PDT

> From: Thomas Kofler <>
> Date: Tue, 24 May 1994 18:48:23 GMT
> 2) The New Syntax
> 2.1) Productions
> 1) The following productions replace the productions of the same
> name in [1]:
> stmt: simple_stmt | block.
> simple_stmt: small_stmt ';' | compound_stmt.
> suite: ':' simple_stmt | block.
> 2) A new production is introduced:
> block: '{' stmt+ '}'.

Instead of '{' and '}' being used (this looks too much like C),
why not something like '<|' and '|>' or ':;' and ';:'
Thus a block would like like:

if a <|
b = 'This is a test'
c = 'What else can we do?'


if a :;
b = 'This is a test'
c = 'This is a test'

You should still be able to write:

if a:
b = 'This is a test'
c = 'This is a test'

I also HATE the idea of needing ';' at the end of lines..
(mentioned below)
Again, This is PYTHON, NOT *C*. Stop trying to make it into C.

> 4) In the production for atom, the clause:
> '{' [dictmaker] '}'
> is changed to:
> '{|' [dictmaker] '|}'.

I don't like this. I myself use dictionaries all over the place and
this would be a major hassle.

> 2.3) Discussion
> White space does not have a syntactic meaning anymore.
> The resulting syntax for grouping statements comes very close to
> C or C++. Empty statements, however, are not allowed although this
> would be possible. Empty statements are sometimes convenient, but
> easily leads to code that does not mean what the programmer means.

Empty statements are not needed.. that is what the 'pass' command is

> The introduction of blocks allows for nesting local scopes of the
> language.

Again. This is not needed if you PLAN out your program. Again, this
sounds like C programming and not Python programming.

> Dictionary literals are rare. Thus, the new syntax for denoting
> dictionary literals is not a loss.

Like hell they are.. Dictionaries are GREAT for "jump tables",
dispatch tables, static tables, and a hell of a lot more.
I use dictionary literals all over the place in my programming.

> I rejected keywords like 'end', 'end if', etc. for the use as block
> closers. First, introducing new keywords is always problematic, and
> many people would not accept that. Second, keywords need more key
> strokes. Third, keywords are less visible than combinations of
> non-alphanumeric characters.

I disagree with the last statement. Actually they are easier to
visually spot.

> 3) Compatibility with Current Syntax
> There is no general compatibility between the current and the new syntax.
> Binary code produced from either current or new syntax might be compatible,
> but this is not a requirement. Implementors are encouraged, however,
> to provide compatibility on the binary level. Note that the new syntax
> does not involve any conceptual change.
> A converter can be provided that transforms source code written in current
> syntax to code in new syntax. This will be important for a smooth and
> quick transition from current to new syntax.

This is NOT the time to change the syntax in a non-compatible way.
people are using Python for production items and now that Python
is posted to the net and gaining acceptance, I feel that this type
of change would cause a lot of people to change. Whatever changes
are made to the language, they MUST be compatible.

> 4) How To Continue
> Requests to change or to add something this draft proposal are welcome
> accepted as long they do not affect the primary aim of eliminating the
> syntactic meaning of white space. The draft proposal will be followed
> by a proposal by the author taking the feedback into account.

I still do not see a need to remove the syntactic meaning of white space
in the language.

Lance Ellinghouse