A Suggestion for Python Colon Syntax

Alex Martelli aleaxit at yahoo.com
Wed Dec 27 11:57:48 EST 2000


<billtj at my-deja.com> wrote in message news:92cu71$9m4$1 at nnrp1.deja.com...
    [snip]
> > 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.

Funny enough, Python survived and thrived for 10 years based on a LOT
of respect for the installed code-base -- and therefore UTTER prudence
in "adding features", because you just don't "retract" a feature later
(breaking people's good code).


> 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):

Yecch.  Redundant punctuation -- the WORST kind, too... ubiquitous
parentheses!


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

Because "A foolish consistency is the hobgoblin of little minds"
(Ralph Waldo Emerson)?


> 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.

Perl is a special case of going overboard in wild inconsistency.
Python's tasteful use of little touches of it here and there is
just my thing (except only for the horrid 'print >> bah' blotch).


> > Guido does.  Now what?
> >
> Guido does, but shouldn't we take also the opinions of the community?  I

No!  You want a language designed by committee?  Take your pick,
there's a wild abundance of THOSE around.

> 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?

In a hypothetical situation where anybody is totally free to choose
which community to "be born" in, and vote with his or her feet by
moving to another with minimal inconvenience, a maximal variety of
regimes might be optimal -- give everybody more choice.

Would you rather listen to a symphony composed by one great musician,
or to one made up, one note at a time, each the fruit of some democratic
political compromise?  The answer is pretty clear to ME -- particularly
since there are so many examples of the latter in the software world.

As long as some designer enjoys AND USES practical veto-right, a
committee can work to enhance a language -- the ANSI/ISO committees
for C did, and Ritchie showed the need for veto rights in his famous
"Noalias must go. This is non-negotiable" communication.  The
Python community (or at least its Guido-selected inner core, the
membership of the 'Python-developers mailing list') plays a similar
role -- they take straw polls and everything.  But our Benevolent
Dictator For Life (BDFL) is the one who decides in the end -- he
lets *good arguments* sway his decisions, but NOT opinions, even
widespread ones.


> 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.

Python is even MORE convention-based than C++ -- for example, if you
design a class with some attribute X that is only meant for subclasses'
use, in Python you just document that *and rely on people's respect for
this design-convention*, while in C++ you can try to enforce it with
the 'protected' keyword (one of the few specific design decisions that
the language designer explains he now thinks were bad mistakes in his
excellent book on "Design and Evolution of C++" -- but, fortunately for
his language's actual use if not for its theoretical elegance, he, too,
respected the installed codebase too much to ever take something away).

If you want a language where everything is strictly enforced, you may
try Eiffel, but I think even that will fail to live up to that ideal.


> 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

That would be bad -- after I type
    if chatty: print "OK so far"
I most definitely do NOT want the next line indented (that would be a
Python syntax error unless I undid the indent manually!).


Alex






More information about the Python-list mailing list