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