[Python-ideas] Retrying EAFP without DRY
steve at pearwood.info
Sat Jan 21 10:38:55 CET 2012
Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
> > Mike Meyer wrote:
> > "retry" will jump back to the start of the try block
> This doesn't sound very intuitive to me.
No, not very. You might not guess what it does, but it's not that hard to
learn: "retry jumps back to the beginning of the try block".
> > -- a limited form of GOTO, with all the pros and cons of this.
> All control flow is a limited form of GOTO. But in this case, retry
> can only go to one place, about as unlike GOTO as I can imagine. It
> certainly doesn't have any cons of GOTO that "while" doesn't have!
The main con that I can think of is that it isn't clear that you're looping
until you reach the retry.
if flag: ...
else: retry # Ah, we're in a loop!
I don't hate this, but nor am I going to champion it. If someone else wants to
champion it, I'd vote +0. It just feels more natural than making retry a block
clause (Mike's proposal), but I'm not really convinced it's necessary.
> It seems to me that rather than a new keyword "retry", I'd want to use
> the existing "continue" here as with other looping constructs. The
> problem is that this would interfere with other uses of continue, not
> to mention that it would be inconsistent with break. While this
> thought experiment doesn't prove anything, it makes me wonder if the
> idea is really coherent (at least in the context of Python today).
continue can't work, because it introduces ambiguity if you have a try inside
a loop, or a loop inside a try. We could arbitrarily declare that try-continue
wins over loop-continue, or visa versa, but whatever decision we make, it will
leave half the would-be users unhappy.
Besides, there's a neat symmetry: you try something, then you re-try it.
(Believe it or not, I've only just noticed this.)
More information about the Python-ideas