Unix: Unexpected behaviour in nested for loops

[peterhinch]

This arose in this forum post

for foo in range(10):
  print(foo)
  for bar in range(10):
    pass
  else:
    continue
  break

Outcome under CPython (prints 0-9) and MicroPython (prints 0 only)

[adminpete@axolotl]: ~
$ upython 
MicroPython v1.8.7-797-ge5e49be-dirty on 2017-06-05; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> import rats26
0
>>> 
[adminpete@axolotl]: ~
$ python3.5
Python 3.5.2 (default, Dec  2 2016, 15:29:25) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import rats26
0
1
2
3
4
5
6
7
8
9
>>> 

[dpgeorge]

Thanks for the report, I can confirm that it's a bug with the optimised for loop. For now, to work around it force the compiler to not generate optimised loops by using an explicit iterator:

xrange = range
for foo in range(10):
  print(foo)
  for bar in xrange(10):
    pass
  else:
    continue
  break

[pfalcon]

@dpgeorge : My understanding is that it's incorrect handling of "continue" scoping in for's "else" clause: it no longer applies to that "for", but to the enclosing "for".

[dpgeorge]

Should be fixed by 4c5f108. Tests added in 4492293

[dpgeorge]

My understanding is that it's incorrect handling of "continue" scoping in for's "else" clause: it no longer applies to that "for", but to the enclosing "for".

No, the else is handled correctly. It was an issue with values remaining on the Python stack when they should have been popped.