Python added style constraints to a computer language without
compromising on language semantics. This has improved the readability
of all Python code and has cost nothing. Eliminating this feature
just opens the door for obfuscated code and would add nothing concrete
to the language.
The original reasoning for white space based scoping still holds.
Advocates for the proposed syntax changes have not produced a set of
rules support the claim that it is wrong to enforce programming style.
They have just declared it to be wrong and assume their rules are
facts. Even if someone or some group claims this to be true, the
burden of proof is on them. Using syntax rules to enforce a
consistent programming style is not wrong. It's just a change from
past practices.
Guido has been beat up enough on this issue and his resolve is showing
signs of weakening. It is time for the observers who have silently
agreed with Guido's choice of syntax to come to his aid. I believe he
should not give in to the pressure of proposals like this one. The
syntax change proposal is full of religious arguments and no
substantive arguments. No one is forcing them to use Python so, as
with religious freedom, programmers have the freedom to follow and the
freedom to leave. If you find Guido's syntax too offensive then
please leave.
Guido, please do not add an alternative to the white space syntax.
Ignore the never ending chorus of cries from the new C and C++
converts. The noise will never stop because each new users is destine
to initially make the same misguided judgment of the syntax. Their
understanding of the advantages will grow as they learn to adjust
their work habits and expectations. There will also continue to be
whining from some seasoned Python users who will irrationally cling to
archaic syntax preferences. There nostalgic yearnings should also be
ignored.
My comments on the RFC are:
Thomas Kofler writes:
> Draft Proposal for a Minor Syntax Change for Python -
^^^^^
This change is far from minor. It breaks every Python program in existence.
> Eliminating the Syntactic Meaning of White Space
>
>
> 0) Introduction
>
> When I learned about Python[1], I found that it is an interesting and
> powerful language -a language I would like to use for serious work. I
> found, however, that the current syntax has a serious drawback:
You may find this a drawback, but I find it a useful feature for
improving the readability of code written by other programmers. The
stated problems appear to be religious issues which do not address
substantive flaws in the semantics of the language design.
> White
> space has sometimes a syntactic meaning. I acknowledge the minor
> advantages of the current syntax, but they do not outweigh the
> disadvantages if programming even in the small-to-medium scale.
Where's the proof that it outweighs the disadvantages. Give us an
example of why Python doesn't scale. I've seen no evidence. In fact,
I find it scales much better than the line-noise like syntax of Perl
or C.
> Since I am firmly convinced that the current syntax is a serious
> problem
I'm convinced that the biggest problem is that someday Guido will give in
and allow an alternative syntax to creep into the language. You state
a problem exists and state your preferences, but you never give proof
of an actual problem.
> -I am not a language lawyer- I worked out this draft
> proposal. I would be very pleased if this work could support the
> spread of Python. The paper contains the following sections:
> - Requirements and Benefits
> - The New Syntax
> - Compatibility with Current Syntax
> - How To Continue
> - Acknowledgements
> - Appendix: References and Materials
>
>
> 1) Requirements and Benefits
>
> 1.1) Requirement: Elimination of Syntactic White Space
>
> The new syntax should eliminate all syntactic meaning from white
> space.
Why? Because you don't like it?
> As a constraint, the resulting syntax should look close to
> the current syntax, and require minimal changes of the current syntax
> and minimal efforts for an implementation based on the reference
> implementation by Guido van Rossum.
>
> 1.2) Expected Benefit
>
> The new syntax makes programs immune against semantical changes due
> to different formating.
The existing syntax is currently immune to semantic changes due to
missing or misplaced braces. A bug is a bug.
> The new syntax eliminates the formating policy as imposed by the
> current language. There is no "true" formating style, and a language
> should not impose any policy on its users, but should provide
> mechanism according to its design goals only.
There may be no '"true" formatting style' for C, Perl, and many other
languages. That doesn't mean there can't be in Python. It's a
feature of the language that many of us like. If you don't this
policy, don't impose it on yourself. Choose a different language.
Your statement, "a language should not ... but should provide
mechanism according to its design goals only", seems a bit dogmatic.
Is this language design rule taken from the __C Programmer's Guide to
Language Design__? It's Guido's language, why not let him try
something new.
> In particular, the new syntax is expected to and will:
> 1) ease the editing of Python code in practice
I have no trouble editing Python as it is. Given that editing is only
done occasionally and that code is read many times, shouldn't the
langauage design focus on being readable. Take a class in touch
typing or find a better text editor if you feel your productivity is
being inhibited by the current syntax.
> 2) ease the use of macro processors and code generators
Macro processors are the bane of good software. Why do you want to
compromise a language to support this out of date technology.
Why do you believe the new syntax make code generation easier? Please
supply some evidence.
> 3) relieve a burden from developers embedding Python into
> interactive applications that allow users to enter Python source
ExOOPS seems to do this with no problem. Perhaps your interactive
applications are poorly designed.
> 2) The New Syntax
[Gratuitous proposed changes deleted]
> 2.2) Examples of Legal and Illegal New Syntax
>
> #------ Legal New Syntax -------------------
> def f(): pass;
> class C: pass;
> #
> if a: ta(); else: fa();
> if a { ta(); } else { fa(); }
> if a:
> if b: tb();
> else: fb();
> # dangling else resolved as usual: it belongs to the most
> # recent 'if', 'for', or 'while', etc.
So I have to manually parse the source code to find the most recent
if, for, or while? This is an advantage?
if b: tb();
else: fc(); fb();
This would be legal code but compare it to:
if b:
tb()
else:
fc()
fb()
It is very easy to visually parse the python code and see that fc()
and fb() are both to be executed if b is not true. Using your syntax,
it is easy to read over the missing braces and expect fc() and fb() to
both to be executed if b is not true because the two funcitons are on
the same line as the else. The example in your syntax would have the
fb() function called regardless of the state of b.
> #
> if a {
> if b: tb(); else: fb();
> }
> # resolves the dangling else and is easier to read
The equivalent existing Python syntax would be:
if a:
if b:
tb()
else:
fb()
Like an indented outline of a book, the existing syntax assists the
visual parsing of the code. Your syntax make writing parsers easier and
allow four lines of code to be compressed to one line. Which syntax
will be of greater value when someone takes over the task of
maintaining this code?
> #
> def f() { pass; }
> def g() {
> { a= 1; b= 2; }
> return k(a,b); # a and b visible!
> }
> # We can write a block any place where a statement is expected:
> # A block allows for grouping, but does not open a new
> # nested scope!
I see no value in being able to do this. The braces around a= 1; b=2;
are superfluous and can only distract a programmer trying to analyze the
code. The following would be silly but legal.
def g(){{{{{{{{{{{{{{{{ a= 1; }}}}}}}}}}}}}}}}
> #
> if a: ta();
> else: {
> fa();
> }
> #
> dict= {||}; dict= {| a:b, c:d |};
> # dictionary literals (display in Python speak)
>
> #------ Illegal New Syntax -------------------
> if a: ta() else: fa();
> # ^^^ missing semicolon
>
> if a: f();;
> # ^^^ semicolon unexpected
> # This could be legal if we have an empty statement.
> #
> while condition {
> condition= f();
> };
> #^^^ semicolon unexpected
> #
> def f() { }
> # ^^^ statement expected
> # This could be legal if we have an empty statement.
Why propose a syntax that requires ';' after we finally got rid of them?
> #------ Current vs. New Syntax
> #
> if a:
> aa()
> bb()
> # ^^^ syntax error: semicolon expected
> # Legal current syntax, but illegal in new syntax
Seems like a rather gratuitous change to a language that isn't broken.
Why do you want to break code to make a change that doesn't fix any
existing problems.
> if a:
> aa();
> bb();
> # Legal new syntax but different semantics. Meaning in current syntax:
> if a:
> aa();
> bb();
I really don't understand why you want to break this.
>
> 2.2) Interactive Use
>
> There is no great difference between current and new syntax
> for interactive use. Statements have to be terminated, of course,
> by either semicolon or a closing brace, depending on what has been
> entered before. The user can take advantage, however, of the new
> syntax. For example:
>
> >>> if c: tc(); else: fc();<NEWLINE>
> >>> # not possible with current syntax!
Yes it is possible. The following works just fine.
>>> def tc():
... print 'tc'
...
>>> def fc():
... print 'fc'
...
>>> c = 1
>>> if c:
... tc()
... else:
... fc()
...
tc
>>>
>
> If it is possible to specify an else part or more exception clauses,
> the user enters an empty line as before to indicate that nothing more
> will follow.
>
> In contrast to the current syntax, this behaviour is accomplished in
> the scanner. In the case of an empty line, the scanner produces the
> token sequence 'pass' ';' if there could be more input.
>
> >>> if c: tc;<NEWLINE>
> ... pass;<NEWLINE>
> >>> while (c) { tc(); c= cc(); }
> ... <NEWLINE>
> >>> # equivalent to enter pass;
How is this an improvement?
> 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.
I frequently use pass to make an empty statement in Python. Why have you
declared this to be 'code that does not mean what the programmer
means'? Eliminating this capability not a feature. It is a step
backward.
> The introduction of blocks allows for nesting local scopes of the
> language.
Python already has nesting. What have you added?
> Dictionary literals are rare. Thus, the new syntax for denoting
> dictionary literals is not a loss.
Maybe you don't use dictionaries but I do. I strongly disagree with
this statement. Your rather cavalier statement is given without proof
and makes the assumption that what you believe to be of value is a
fact.
> 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.
What do you mean it doesn't involve conceptual changes?
> 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.
Will you convert all my code for me and certify that it will all work
without semantic variation? Your gratuitous change proposal will cost
me a couple weeks work to convert and test my existing code.
>
> 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.
As long as you agree with me, your comments are welcome?
> 5) Acknowledgements
>
> Thanks to Guido van Rossum for inventing and conducting the Python
> reference implementation, and many other people contributing to
> Python.
And thanks to Guido for resisting the temptation to give into the
temptation of adding everybody's pet requirement to the language.
Michael