> > [tim, unwittingly making the problem worse]
> > ... Section 6.9 (The 'continue' statement) of the Reference Manual
> > attempts to document this, but I believe should say instead:
> >
> > 'continue' may only occur syntactically nested in a 'for' or 'while'
> > loop, not nested in a function or class definition, and not nested in
> > the 'try' or 'finally' clauses of a 'try' statement (it may occur
> > nested in an 'except' clause of a 'try' statement though).
> [robin, unwittingly proving tim did make it worse]
> ... I don't understand all the restrictions on continue's use listed
> above. Do you really mean not in a function definition? *Everything's*
> in a function definition! ...
Indeed, I didn't mean that, & neither did Guido. One more try:
'continue' may only occur syntactically nested in a 'for' or 'while'
loop, and applies to the nearest enclosing such loop. However, it
must not be nested in a 'def', 'class', 'try' or 'finally' block that
is itself nested in the loop. Note that it may be nested in an
'except' block nested in the loop, though.
So these nesting patterns are bad:
for ...:
try:
continue
for ...:
try:
...
finally:
continue
for ...:
def ...:
continue
for ...:
class ...:
continue
but these are fine:
for ...:
try:
...
except ...:
continue
class ...:
def ...:
try:
...
for ...:
...
continue # there's a 'try', but the 'for' is closer: OK
...
...
except ...:
...
for ...:
...
continue
...
...
finally:
...
for ...:
...
continue # ditto
...
...
So it's not nearly as restrictive as you were led to believe <wink>.
As to where the restrictions come from:
+ It doesn't make _sense_ to stick a continue in a nested 'def' or
'class'.
+ I _suspect_ it's not allowed in 'finally' just because the implementor
had better things to implement at the time <wink>.
+ I _suspect_ it's not allowed in 'try' because (unlike as for 'finally')
it was technically difficult to do so, and-- again --because there were
better uses for the development time.
hang-in-there-it-will-all-be-intuitively-obvious-in-a-month-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp