Menu doesn’t support pew.GameOver

[cwalther]

(Moved from pypewpew/pewpew-m4-v8#1)

The current menu (main.py) does not restart when a game exits by throwing pew.GameOver (as Othello does), but drops you into the console with a traceback, leaving no way out except a power cycle.

This turns out to be nontrivial to fix when the goal is to keep the del sys.modules['pew'], which seems a sensible thing to do to free up memory for non-pew games. My first naive attempt to stow away GameOver in a variable before deleting pew does not work, because then the GameOver we are trying to catch comes from a different instance of the pew module than the one thrown. What I think would work is to define the exception class in another module that can stay loaded and then doing from othermodule import GameOver in pew.py. That other module could be ugame or stage, assuming that because pew is implemented on top of them they need to stay loaded anyway. And maybe a GameOver exception would be a useful thing to have in ugame/stage games anyway?

[deshipu]

The exception still keeps a reference to the module, so if you "stow away" it, the module won't get deleted from memory, even worse, because it will be deleted from sys.modules, a second copy will be loaded, as you discovered.

There is some discussion upstream about a feature that would allow me to simply restart the device while specifying which file to run after it has restarted, which would solve all problems with memory. Unfortunately that will also make it impossible to handle the GameOver exception in code. See adafruit/circuitpython#1084

[cwalther]

The exception still keeps a reference to the module

Is that so? I don’t see any reference in the Python-accessible part, is it hidden inside? There is the __module__ attribute, but that’s just the name of the module, not the module object.

Regardless, since the GameOver exception was never documented, I guess it’s my own fault for using it in Othello, and I could easily stop doing that, it would just make the code a little longer. If it were to be eliminated entirely though, I would hate to lose the shortcut of pressing all four directional buttons to exit a game (on the platforms where it is implemented – not the PewPew M4).

The reload idea is interesting. If there were a pew.exit() function as you propose there, I could replace my raise pew.GameOver() by that and wouldn’t need to complicate the code.

[deshipu]

Or we could simply make GameOver inherit from SystemExit exception?

[cwalther]

And then in main.py do

try:
    __import__(selected)
except SystemExit:
    pass

you mean? That’s a good idea. It would also change the effect of sys.exit() from going to the “Code done running” state to rebooting into the menu, which seems like an improvement.

It would effectively unify the three ways of exiting by running off the end, by sys.exit(), and by raising GameOver into a “successful exit”, and if #1084 lands in the extended version that allows us to tell it to restart after a successful exit, it would then automatically treat them that way. In the basic version that always ends with “Code done running”, the pew.exit() function would still be needed.

Do we want to distinguish sys.exit() with a nonzero code as “unsuccessful”?

[deshipu]

No, then don't catch it all, let it propagate and end your program as normal.

Alternatively, we could put code that reset the microcontroller in the GameOver initialization, so that the device restarts as soon as you create the exception to raise it.

I don't see a reason to distinguish exit codes at the moment.

[cwalther]

No, then don't catch it all, let it propagate and end your program as normal.

But then how does that solve the problem? Then you still end up on the “Code done running” console after Othello instead of back in the menu (because it terminates the menu along with the game). Just without the traceback, but that’s a cosmetic detail.

Alternatively, we could put code that reset the microcontroller in the GameOver initialization, so that the device restarts as soon as you create the exception to raise it.

Interesting idea. That seems a bit hacky and potentially unexpected, but let’s keep the idea in mind when thinking about a solution for after #1084.

Too bad CircuitPython doesn’t have sys.atexit() from MicroPython.

[deshipu]

Oh, sorry, I'm already thinking assuming that #1084 lands. With a bit of luck in will be in 6.0, which is the earliest we could push new pew.py into CP anyways.

[cwalther]

In that case I think the best way forward is to present a prototype implementation of #1084 that fulfills our needs, which I have just done.

[deshipu]

Awesome, thank you for working on this!

[cwalther]

Shall we submit the deriving of GameOver from SystemExit to CircuitPython for 6.0 (for PewPew M4 and PewPew Standalone)? I think that would be useful to have whether or not #1084 lands. If not, then I would like to at least have python-ugame/circuitpython-stage@852867c in 6.0.

[deshipu]

Good point. I will do that.

[deshipu]

adafruit/circuitpython#3503

[cwalther]

Don’t forget pewpew-game/pew-pewpew-standalone-10.x which is also a CircuitPython submodule. (Or were you thinking of only doing it for the PewPew M4? My idea was to have it the same in all pew libraries. Also the others, eventually, but we can change those independently of CircuitPython releases.)