A Suggestion for Python Colon Syntax

[billtj at my-deja.com]

> So does Guido, but it's rare, and in this case you're ignoring that he
> *already decided*.

Tim, people opinion can change over time, and hopefully Python does not have
the principle that once a feature is already decided, it can never be
changed.  I think to survive, a language has to be flexible to follow
(rapidly) changing technology and therefore modify some of its own
characteristics.

> Yes; I agreed to that in my first msg.  It doesn't matter, though, in the
> sense that Python is not about minimizing keystrokes (not even so much as
> Perl is, let alone extreme one-liner languages like APL or J).  It's much
> more about maximizing readability.  It may be that you're in a minority who
> does not find that the trailing colon increases readability?  It increases
> readability for me, and that matches the testimony of most people who've
> chimed in on this issue over the years.

I think there is some inconsitency here.  If Python is really not about
minimizing keystrokes but more about maximining readability, then I have
at least one counter-point:  Why don't add a pair of parentheses after the
clauses such as:

    if (xxxx xxxx xxxx):
        xxxx xxxx xxxx
        xxxx xxxx xxxx

I think this is even more readable.  Also Python is not consistent in
parentheses:  No parentheses are required after if, for, etc., but parentheses
are required for function argument in a def statement:

    def func (arg1, arg2):

Just like in Tcl, why not make everything consistent?  Like

    def func arg1 arg2:
        xxxx xxxx xxxx

    if xxxx xxxx xxxx:
        xxxx xxxx xxxx

It will then be easier to memorize the basic syntax of Python.  Because every
time I have to switch between C/C++, Perl, etc., I have to look up the
books just for syntax.

> ABC was never popular.  And I'm not sure what more people being familiar
> with Tcl has to do with this.  That *may* influence a decision to add
> semantic features (like, say, file events) someday, but is unlikely to have
> any influence on future syntax -- the languages are worlds apart
> syntactically.

The relationship between Tcl and Python, to me at least is, after the first
keyword such as if, for, etc., then we just add words after that without
needing any parentheses, etc., except the colon in Python.  Yes, in Tcl we
need braces after if, but that is because of basic syntax of Tcl, and not
because it is for "if" or for "for" needs.  I myself programmed in Tcl before
I used Python.	For a more general example, the book Tkinter assumes that
some people have programmed in Tcl/Tk before they start using Tkinter.	I
always see things like "Python for Tcl programmer", and not vice versa. 
Therefore, in the world of Tk, I bet there are a lot people migrating from
Tcl to Python and probably almost none from Python to Tcl.

>
> > I can see clearly the big difference (as I have experienced) between
> > using indentation and curly braces; it makes really consistent coding
> > style.  However, I don't see the colons as falling into the same
> > category.
>
> Guido does.  Now what?
>
Guido does, but shouldn't we take also the opinions of the community?  I
don't like to make this analogy, but in the history, there were/are
communities ruled by kings, and there communities ruled by
democracy.  Which one works better for the welfare of the community?

> > Yes, Guido wants everybody to use colons at the end of the clauses,
> > but right now what prevents someone to put semicolon at the end
> > of every statement?
>
> Some people do.  When they do it public, we ridicule them.  Then they
> usually stop <wink>.

Tim, if you don't allow people to, why don't you just make it part of the
language syntax?  Then everybody will be happy.  People who use semicolon can
be stopped by the interpreter and immediately fix the problem, and you don't
have to "police" the people and you will have more time for other fun things
:).

The problems with C++ is a lot of software construction is based on
conventions, and not part of the language itself.  But because it is based on
conventions, people can abuse them.
>
> >  Just compare the two or three formats:
> >
> >     xxxx xxxx xxxx:
> >         xxxx xxxx xxxx
> >         xxxx xxxx xxxx
> >
> >     xxxx xxxx xxxx:
> >         xxxx xxxx xxxx;
> >         xxxx xxxx xxxx;
> >
> >     xxxx xxxx xxxx
> >         xxxx xxxx xxxx
> >         xxxx xxxx xxxx
> >
> > Which one do you think is the most consistent in layout?  To me, it
> > is not the first one.
>
> The most consistent would be this:
>
>     xxxx xxxx xxxx
>     xxxx xxxx xxxx
>     xxxx xxxx xxxx
>
> That is, consistency is a red herring.

No, because then you lose the indentation which without question has been
advocated since the time of structured programming.
> > ...
> > But the semicolon at the end of the statement break the Pythonic
> > rule.
>
> If you put them there, yes.  Happily, nobody does; for example, you won't
> find a semicolon at the end of any code stmt in any .py file in the standard
> distribution.  When conformity is voluntarily and universally achieved,
> there's no need to legislate it.
>

Python could also have achieved the indentation through voluntarity, but it
forced it through the syntax.  Again, I think it is better if everything is
consistent.  If something is to be universal, force it through the syntax. 
If syntax allows something to happen, then people, in my opinion, must be
allowed to use it.  By having part rule and part voluntarism, it creates
extra work, especially in the voluntarism part.  And if it has been
universally accepted, then I guess nobody will complain when you force it
through the syntax, such as from now on no semicolon is allowed at the end of
the line, unless it is followed by another statement on the same line.

> > ...
> > I am not too familiar with the parsing stuff.  However, in my
> > simplistic opinion, Python is not a free-form language like C
> > or Perl.  Therefore, probably it is reasonable for any parser
> > to breaks a Python code first into lines, even in backward
> > parsing, instead of parsing it token by token first.  In parsing
> > backwards, can then it just detect first that the line is at
> > different indentation level rather than try to detect the colon?

> When you're writing code and hit the ENTER key, good editing environments
> try to *suggest* sensible indentation for the new line.  In part, that
> requires guessing whether the statement just ended opens a block (in which
> case the new line should be indented more) or not (in *most* of which cases
> the indentation should be duplicated from the statement that just ended).
>
> Regular expressions don't suffice for this determination, so it's a lot of
> painful character-at-a-time parsing.  The trailing colon is a great hint:
> if the stmt that just ended doesn't end with a colon, there's no need to
> endure the expense of further analysis (the line that just ended can't
> possibly open a new block without that colon).  Speed is important here,
> because the user expects the response to the ENTER key to appear
> instantaneous, and the parsing code is usually written in an interpreted
> language.  The Emacs Python mode is greatly helped by some parsing
> primitives supplied by elisp and coded in C.  IDLE (and by inheritance, also
> PythonWin, which shares IDLE's auto-indent code) has a much rougher time of
> it, being coded in pure Python, and having the added speed burden of needing
> to talk to a Tk text widget thru the Tkinter interface layer to find out
> anything about what's in the buffer (even worse, that's indirected in Python
> code too, so that PythonWin can talk to the Scintilla text widget instead).
>
> Every quirk of the syntax is exploited mercilessly to reduce processing
> time, and that's a hard job (I wrote both of those parsers, so I'm not just
> guessing about that); the use of colons to open blocks is one of the quirks
> that can be exploited a lot.  The IDLE code would need to be redone from
> scratch without it (IDLE doesn't preserve any of the alphanumeric characters
> now:  it squashes all runs of alphanumerics into a single "x" character,
> because it can do that quickly, and then chew over far fewer total
> characters at Python speed).

I'm sorry, Tim, my background is not too strong in this parsing department. 
My question is, can you just detect the first word of the line?  I think
there are only a finite number of them, such as class, def, if, for, etc.  If
the first word is any of these, then indent the next line, without regard of
the colon.  Is detecting any of these words at the beginning of line much
harder (apart from more CPU time) than detecting a colon at the ending of
line?  (I don't mean programmatically.	Yes, of course there will be more
code to detect the various words than detecting the single colon.  But at
least, in principle, the two are equivalent, right?)

>
> At this point, if you want to keep pushing this the way to do it is to open
> a PEP:
>
>     http://python.sourceforge.net/peps/
>
> While a PEP needs an implementation before it can become final, the PEP
> author need not write the implementation, and the PEP can be accepted before
> an implementation is even started.  What you would need to do is make a
> compelling (to Guido) case, and identify all the consequences and how
> they'll be dealt with.  The process is covered in more detail in
>
>     http://python.sourceforge.net/peps/pep-0001.html
>
> I expect the PEP will be rejected, but that doesn't mean it will be.  Guido
> did surprise me once, in about 1995 <wink>.

OK, I will do it.  Thanks.  Hopefully Guido will be more open and generous
during the holiday season :) .

Regards,

Bill


Sent via Deja.com
http://www.deja.com/