Suggestion for (re)try statement

Alex Martelli aleax at mail.comcast.net
Thu Nov 3 00:13:52 EST 2005


Sori Schwimmer <sxn02 at yahoo.com> wrote:
   ...
> 2) Rocco Morreti wrote:
> > What is so repugnant about the equivalent, currently
> valid way of writing it?
> Nothing "repugnant". We have in almost all procedural
> languages an "if-else" construct, and a "case" or
> "elif" as well.

Python has no 'case'; 'elif' is just one of the clauses that an 'if'
statement can have.

> Same with "for", "while",
> "do...while".

Python has no 'do...while', and its for and while statements have
drastically different semantics.

> It's all about convenience, not about
> getting to bare bone equivalents.

Fattening the language up for 'convenience' is generally not the Python
way.

> So, I thought it's convenient to have the extra
> functionality in the try statement, and am willing to
> see what others think about it.

My reaction is one of utter revulsion, for what it's worth.


> I'm not trying to convince anybody. In the democratic
> state-of-mind in which I live, the idea will be taken
> in consideration if it is found useful by many, not by
> one, even if the one is the almighty Guido. Not that I
> don't respect his opinions, or his work on Python, but
> I think that "popular demand" should prevail. Not

Python did not get to its incredible success of today by basing its
design decisions on "popular demand", which appears to be an even
crazier notion than "design by committee".  Design by a committee tends
to produce a lot of bloat; design by "popular demand", i.e. a group of
people substantially larger and less selected than even a committee,
would no doubt produce even more bloat.

If you want bloat, go use a bloated language (there are so incredibly
many of them, that you'll have your pick!), and please leave alone one
of the few languages that have managed to at least control the amount of
cruft they have accumulated over the years (we keep hoping for a REMOVAL
of many legacy features come Python 3.0 time, in fact).


Alex



More information about the Python-list mailing list