[Python-ideas] Retrying EAFP without DRY

Mike Meyer mwm at mired.org
Sun Jan 22 23:59:51 CET 2012

On Sun, 22 Jan 2012 13:52:52 -0800
Chris Rebert <pyideas at rebertia.com> wrote:
> On Sun, Jan 22, 2012 at 1:30 PM, Mike Meyer <mwm at mired.org> wrote:
> > 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:
> <snip>
> >> 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
> > - other exceptions missing the attributes we added to ours - was the
> > code we want to run after handling them, we're left with LBYL or DRY
> > or wrapping a loop around the code when it wasn't really a loop.
> The thing is, until this message, you never described any concrete
> details about your specific use-case, other than that you had one.
> Now you have, but in prose (which is regrettably imprecise) rather
> than code; I'm still not entirely sure what your use case looks like.

I can't give you the actual code (without having to deal with lawyers)
because it comes from a client's proprietary product. I could make up
code, but that's no better than the pseudo-code I gave in the OP.

> As best I can parse it, a nested try-except sounds like it would work.

I don't see how. Here's the pseudo-code example from the OP that most
resembles the code we finally committed, doing LBYL instead of EAFP:

    if not isinstance(x, my_class):
       x = fixup(x)

That doesn't show you where the exception would happen though, so here
(also from the OP) is the version that violates DRY:

        x = fixup(x)

The only thing the prose deception added to the above is that x is
known to be an exception, and we wanted to make sure it had an
appropriate attribute. The fact that it's an exception isn't really
relevant, but that we needed it to have a specific attribute means
those two might be better written as:

    if not isinstance(x, my_class):
       x = my_class(fixup(x))


        x = my_class(fixup(x))

If you've got a nested try/except solution that does EAFP and DRY, I'd
be interested in seeing it. The OP included some loop-based variants
as well.

> People like use-cases because they can reveal motivations or
> subtleties that often turn out to be significant, and they can more
> easily critique them than completely abstract/general cases.

Which is why I provided the best I could under the circumstances and
why I'm one of the first to ask for them when they aren't present.

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