Message378178
After studying Mark's patch and the rest of the code, I understand the for loop oddity.
The else block of the for loop comes after the
compiler_pop_fblock(c, FOR_LOOP, start);
So you can do this all day and it won't complain:
for x in '1': pass
else:
for x in '2': pass
else:
for x in '3': pass
else:
for x in '4': pass
else:
for x in '5': pass
else:
for x in '6': pass
else:
for x in '7': pass
else:
for x in '8': pass
else:
for x in '9': pass
else:
for x in '10': pass
else:
for x in '11': pass
else:
for x in '12': pass
else:
for x in '13': pass
else:
for x in '14': pass
else:
for x in '15': pass
else:
for x in '16': pass
else:
for x in '17': pass
else:
for x in '18': pass
else:
for x in '19': pass
else:
for x in '20': pass
else:
for x in '21': pass
else:
for x in '22': pass
else:
for x in '23': pass
else:
for x in '24': pass
else:
for x in '25': pass
else:
for x in '26': pass
else:
for x in '27': pass
else:
for x in '28': pass
else:
for x in '29': pass
I guess the same goes for while loops, and the else of a try-except.
Since If blocks were deliberately left out of this game, I'm assuming that this "static nesting" is actually number of frames, rather than true static nesting. If that is the case then there is no issue here and we can close this ticket.
But if this is something to be fixed, then I am happy to make a patch along the lines of Mark's (which I partially already have). |
|
Date |
User |
Action |
Args |
2020-10-07 20:51:18 | iritkatriel | set | recipients:
+ iritkatriel, Mark.Shannon, serhiy.storchaka, myzhang1029 |
2020-10-07 20:51:18 | iritkatriel | set | messageid: <1602103878.6.0.15353500752.issue39934@roundup.psfhosted.org> |
2020-10-07 20:51:18 | iritkatriel | link | issue39934 messages |
2020-10-07 20:51:18 | iritkatriel | create | |
|