Python environment after program ends

[poesel]

I'm using the pymakr plugin with VSC on Windows. After a program ends or is interrupted I'm back on the REPL. So far so good but all programm objects are destroyed. I can of course manually type in the commands to recreate them but this is tedious.

Is there a way to keep the current environment (objects, variables, etc...) after a program ends or is interrupted?

Thanks!

[crumble]

You have to store your desired objects in global variables or write log files.

Have a look on the lifetime of objects and why it is good practice to keep it either short or keep them as long as possible alive.

Have a look on unit tests as well. The concept may be only useful for a small set of your methods, but it is a great concept for testing the methods which have not to deal with side effects. There may be no fancy tool for micropython. But you can use the idea to write yourself some simple test packages and upload/call them when needed.

[poesel]

I don't think you understood what I'm asking for.

Simple example: I have a device on the i2c bus I want to talk to. So in my program I have an object 'i2c' from machine.I2C. The program ends or is aborted and 'i2c' is gone. If I want to test I have to recreate that object in the REPL.
Is there a way to keep that object alive?

[robert-hh]

@poesel If you start a script, let's call it my_script.py, manually with import or from main with import, and that script finishes regularly, you have an object call my_script in repl, and dir(my_script) shows you all objects created within. So you would have that i2c object under the name myscript.i2c.
If you aborted my_script e.g. with Ctrl-c, you can re-import it and have then all objects visible. The re-import will not run the script again.

[poesel]

Thanks to both responders - the confusion was on my side. I had a wrong understanding about how this works.
That what I wanted is not possible but you can get pretty close with a construct like that:

...
i2c = None
ds = None

def main():

    global i2c
    global ds
...

I guess that is what @crumble meant. Variables in a global scope survive program termination, those inside a function (like main() ) get destroyed when the function ends.

[aen]

@crumble do you have a good pointer to unit testing these devices?

[andreas]

Dear @aen,

do you mean real DUT testing or just some environment which will help you by emulating the hardware through mocking the MicroPython API to some extent?

Within the Terkin Datalogger, we've built upon esp32-machine-emulator and expanded it by a large amount to conduct some pretty tests you will find at [1]. This MicroPython test harness is essentially based on CPython and is therefore probably different from other players in this field. However, it gives us much confidence on many levels and helped tremendously while refactoring the growing code base even when not being invoked on the device itself.

Maybe this helps?

With kind regards,
Andreas.

[1] https://github.com/hiveeyes/terkin-datalogger/tree/master/test

[crumble]

@aen

By now I have written my own tests without using a library. I had some trouble to fit my stuff into a LoPy 1. I still have to write me some scripts for precompiling and splitting the full source into testable projects. I am using Atom which seems not support such fancy things out of the box.

I found this library the other day, which seems to run with the pycom implementation:

micropython-lib on github