lib/utils/pyexec: Don't treat SystemExit as "forced exit".

[pfalcon]

"Forced exit" is treated as soft-reboot (Ctrl+D). But expected effect of
calling sys.exit() is termination of the current script, not any further
and more serious actions like mentioned soft reboot.

[pfalcon]

I don't know how we ended with treating SystemExit as a reboot, but time to break that tradition ;-). As outcome of porting upip to baremetal.

[dhylands]

We had a soft reboot and a hard reboot function for the pyboard, and we decided that throwing a SystemExit would be better than having a softreboot function, and since that's all that sys.exit does that's what we did.

See: #826

[dpgeorge]

See also #924.

If we remove this behaviour (SystemExit not doing a soft reset) then we'll need to add machine.soft_reset(), or something similar, as a programatic way to do soft reset.

[dhylands]

If somebody wants the SystemExit exception to do something different, then you just need to intercept the exception and do what you want and you won't get the soft reset behaviour.

[deshipu]

What command can I use to get back to the REPL then?

[dhylands]

What command can I use to get back to the REPL then?

If you leave main.py then you return to the REPL.

[deshipu]

How can you leave main.py from the middle of your function?

[dhylands]

If I write my main.py something like this:

def main():
    try:
        # do some stuff
     except MyException:
         return

main()
print('After this the REPL will be executed')

Then you can raise MyException from anywhere in the program and you will leave main.py

Using the function main is completely optional. But as soon as execution returns from main.py then the REPL is executed.

[deshipu]

I see, that could work.

[pfalcon]

If we remove this behaviour (SystemExit not doing a soft reset) then we'll need to add machine.soft_reset(), or something similar, as a programatic way to do soft reset.

Sounds good, can you please prepare that?

[pfalcon]

If somebody wants the SystemExit exception to do something different, then you just need to intercept the exception and do what you want and you won't get the soft reset behaviour.

The problem is that people exactly don't want SystemExit to do something different to what it's supposed to do. And that's: 1) terminate currently running application (being done); 2) drop to "command line" - not being done, instead, something else is done.

[dpgeorge]

We could add machine.soft_reset(). But then it's arguably a tiny bit inconsistent with machine.reset() which should then be called machine.hard_reset(). Instead we could add an argument to the existing machine.reset() which indicates what kind of reset (eg hard, soft, with default being hard). But then you'd need constants for the kind of reset. It could be a boolean, ie machine.reset(soft=True) but that's not very friendly. Probably machine.soft_reset() is the right thing to do.

[pfalcon]

We could add machine.soft_reset(). But then it's arguably a tiny bit inconsistent with machine.reset() which should then be called machine.hard_reset().

I don't see a big inconsistency here. There's a real reset, and "soft reset", which isn't even available (fully) for each target.

Instead we could add an argument to the existing machine.reset() which indicates what kind of reset (eg hard, soft, with default being hard). But then you'd need constants for the kind of reset. It could be a boolean, ie machine.reset(soft=True) but that's not very friendly.

Ack, I'd say that's going down the rabit hole. If soft reset is so important, let it be a top-level function. I personally know only one important usage for it - soft-resetting between tests when running on-device testsuite. Otherwise, it's optional, convenience feature.

Probably machine.soft_reset() is the right thing to do.

+1

[pfalcon]

Ok, to have further progress on this, I'm going to merge this (to prepare upip for esp8266 for release), and created #2508 for machine.soft_reset() part.