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?'
|>
-or-
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
for.
> 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 lance@fox.com