[Python-ideas] Retrying EAFP without DRY (original) (raw)

Mike Meyer mwm at mired.org
Sun Jan 22 22:30:14 CET 2012


On Sat, 21 Jan 2012 11:46:19 +0000 Paul Moore <p.f.moore at gmail.com> wrote:

On 21 January 2012 07:47, Steven D'Aprano <steve at pearwood.info> wrote: > This sounds like retry should be a flow-control statement, like continue or > break, not a block. E.g.: > > try: >    something() > except ValueError: >    if condition: retry >    else: raise > > > "retry" will jump back to the start of the try block -- a limited form of > GOTO, with all the pros and cons of this.

That's the way I would interpret a "retry" statement - and it's nothing like the OP's proposal as far as I can see (where retry introduces a suite).

Yes, it's not much like what I proposed. But it does solve the same problem, and in a much better way than I proposed.

Because of that, I'm not going to try and fix the error in the OP of not translating the proposal to proper Python :-(.

I'd be -1 on a retry keyword that worked any way other than this (simply because this is "clearly" the most obvious interpretation). Whether a retry statement is worth having at all, though, is something I'm not sure of - I'd like to see some real-world use cases first. I've never encountered the need for it myself. And I can't honestly imagine why the while True...try...break" idiom would ever not be sufficient.

I saw a number of request for "real world uses cases". I thought I covered that in the OP. This ideas was prompted by a real world use case where we wanted to wrap an exception in our own private exception before handling it. Because the code that would raise the exception

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



More information about the Python-ideas mailing list