Suggestion for (re)try statement

[Sori Schwimmer]

0) Sorry, I don't know how to post a reply in the same
thread.

The "i += 1" line is almost certainly wrong.

You're certainly write, as I acknowledged in a follow
up "suggestion for (re)try statement - correction'

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. Same with "for", "while",
"do...while". It's all about convenience, not about
getting to bare bone equivalents.

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.

And remember - your goal isn't ultimately to

convince me or someother
person on comp.lang.python, it's to convince Guido

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
trying to say that the "benevolent dictator", the
modern Franz-Josef, is not listening...

Sorin



__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs

 

[Rocco Moretti]

0) Sorry, I don't know how to post a reply in the same
thread.

Usually it is simply hitting the "Reply" button/link/key combination on
your mail/news reader when the post you want to reply to in view. (If
you want reply to multiple people, you can always reply to the original
post, or reply to one, and just treat the topics from all of them.)

2) Rocco Morreti wrote:

First off, let me say that my message wasn't meant to scare you off - it
was constructive criticism, appraising you of what would be necessary if
you actually want the construct in the language. If you're just shooting
the breeze/navel gazing, I apologize for harshing your cool.

>
Nothing "repugnant".

"Repugnant" was probably too strong a word. The point I was trying to
make was: If you want such a construct added to the language, you need
to justify all the hassle & effort of introducing the new syntax. Given
that there is a way to accomplish the same thing now, you would need to
show that your way is not just as good, but better than the current way.

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

Nothing wrong with convenience - you just have to show that the
convenience would be used often enough to justify the hassle. It'd be
awfully convenient to have a passenger jet parked in your garage - but
you probably wouldn't use it frequently enough to justify the expense of
maintaining, fueling, and licensing it.

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.

My comment made with the assumption that you were trying to actively
promote the construct, rather than floating it as a trial balloon. I was
aiming at keeping you from getting annoyed later on when your petition
with hundreds of signatures gets shot down by Guido. Despite your
state-of-mind, in practicality, Python is not a democracy - language
constructs live or die by the will of Guido. If you actually want the
construct in the language, a comp.lang.python plebiscite isn't going to
do it - you'll need to convince the BDFL that it's a good idea. Now,
Guido isn't totally ambivalent to the masses - if a large number of
people are for it, there's a good chance Guido will be for it too. But
you're not aiming for a popularity contest - what'll convince people
(including Guido) is good arguments as to *why this construct is better
than what we have now,* and *why it will be worth the hassle of
implementing and maintaining it*.

 

[Brigham Brown]

It doesn't seem like a very useful construct, because you won't know at
what point the code failed in the try block, so it could execute code
at the beginning of the block several times if the error was in the
middle. That could be weird.

So, it would probably only be useful for one line try blocks.

I wonder if you would have thought of the keyword was something other
than try. For example, if it was errorcatchingblock, would you have
thought of this new construct?

 

[Alex Martelli]

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