[Python-ideas] Retrying EAFP without DRY

[Mike Meyer]

On Wed, 25 Jan 2012 10:28:06 +0900
"Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> Mike Meyer writes:
>  > So long as you incorrectly see this as "just another looping
>  > construct", your conclusions will be flawed.
> That's unfair.  Nobody said "just".  If anything, you were trying in
> earlier posts to maintain the opposite extreme ("not a looping
> construct").

I don't know that nobody said "just". What got said by Nick -
repeatedly - was "We don't need another looping construct." I don't
think it's reasonable to dismiss it without considering how it works
in the other roles for which it's suitable.

>  > The point is to make the try statement more powerful.
> Not on python-ideas, it isn't.  Here, the point is to make Python more
> expressive (including clarity in "expressive").

Didn't we just have a discussion about the ambiguity of English, and
how amorphism isn't pythonic?

The point of the *proposal* is to make the try statement more powerful.

The point of the *list* is to make Python more expressive.

The point of the *thread* is to see if the former does the latter.

Given that intro, I think the conclusion is "not this proposal", with
opinions ranging from "we don't need it at all" to "Might be nice, but
costs to much for the expected use cases."

In thinking about it, I think it's to special purpose. There are at
least four interesting variants of "retry": 1) start the block from
the top; 2) start the block somewhere internally (and where?); 3&4)
Same two, disabling the except handler that ran the retry. It's not
clear there's even a sane way to define #2.

      <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org