[Python-ideas] Retrying EAFP without DRY

[Steven D'Aprano]

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.


try:
    ...
except Spam:
    ...
except Ham:
    ...
else:
    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.)



-- 
Steven