Python 2.0

[Kumar Balachandran]

What you said is quite wrong. Since Python provides closures, I can
change my programming style to be completely different from the
standard C or Fortran style and use a functional interface. Or, I
could just as easily implement a message-passing interface. So, your
comment about beauty in the language due to discouragement of
individuality is not grounded in reality. The issues that a good
programming language should address include a structure that makes it
easy to use, write in and debug as well. The first and the last are
somewhat marred by the subject of my complaint.

It is quite clear that the authors of the language treat the design of 
the syntax very religiously, and my intent is not to denigrate their
efforts, but I must point out that valuable criticism rarely comes
from people that have accepted the philosophy being espoused, but
rather from persons that are able to rise to a metalevel corresponding 
to the system (in this case Python).

I like to quote an analogy that occured to me sometime ago. When I
started learning C many years ago, I wondered how life without
malloc had been possible. Then I learnt C++ and was equally enamoured by the
new operator and the concept of destructors. Finally I learnt Scheme
and Lisp, and now wonder why people use languages without closures and 
garbage collection. I still have to master continuations, something I
feel ashamed about constantly. The problem of course is that Lisp and its
dialects are like Latin -- quite difficult to use with too many tools
for any given task. The notation tends to throw people off as
well. So, in any collaborative work we have to settle for a lesser
language such as Matlab (blech!)  or Python. What do we get out of it
-- we get closures. We also get a nice interactive environment with
easy prototyping ability. But wait a minute, it's like FORTRAN. It uses
indentation and blank lines as part of the syntax. At least it does
not require a label in a particular column of the line. In conclusion, 
lets face the fact that that design decision was flawed, and people
have to conjure up excuses to save face. 

I did suggest "wend" instead of "elihw", and in any case I was not
presenting a specification, just a suggestion. 

>>>>> "Charles" == Charles G Waldman <cgw at fnal.gov> writes:

    Charles> I vociferously disagree that adding junk like "elihw"
    Charles> adds anything to readability.

    Charles> And one of the beautiful things about Python, especially
    Charles> in projects with more than one programmer, is that it
    Charles> explicitly *discourages* individual programmers from
    Charles> developing their own coding styles, since in general
    Charles> there are *not* multiple ways to do the same thing.
    Charles> "Optional" syntax is very much against this spirit.