MicroPython Forum (Archive)

I asked this question on StackOverflow and someone advised me to post here.

Does the memory layout different a lot? Is it difficult to share object between CPython and MicroPython?

The backgroubd is that I want to use Python like LUA. To use a full CPython eval() or exec() is too dangerious, I hope that I can have a simplified version of Python, which is sandboxed and not have access to my operating system's syscall.

I hope there is a way to build a 'port' that can run in a CPython interpreter process, and only use a limited builtin modules or functions provided by the MicroPython

Interesting question!!

It's relatively straightforward to embed MicroPython into any C program. Especially if you just want to do a single exec/eval, rather than having it running code in the background -- i.e. just spin up the VM, allocate some stack and heap, execute a string, tear everything down.

micropython/examples/embedding has an example of this.

The memory layout is very different though, and sharing objects directly is not possible -- you will have to build wrappers for anything that you want to be accessible from MicroPython.

I found that there is a Javascript port, so I think a Python port should also work.

Another problem is that, MicroPython has many global status, which makes it hard to have multi MircoPython interpreter instance run in a single Python process.

The final target for me is to have many safe and simplified python interpreter, embedded into a Python web application, which receive clients' uploaded scripts that have custom logic and run it. The embedded interpreter should have access to the hosting CPython's object so the clients' custom logic can use some API to interact with the data in CPython. All the above can be implemented in Lua, but I hope I can use Python to achieve that. Lua has a small user group and it's not good at dealing with 64bit Int (Lua 5.3 has support for int but the Lupa project for python only support Lua 5.2)

myrfy001 wrote: ↑

Mon Nov 04, 2019 5:07 am

Another problem is that, MicroPython has many global status, which makes it hard to have multi MircoPython interpreter instance run in a single Python process.

Yes, this is a problem for your use case.

That said, almost all the global state is in a single variable -- mpstate.c : mp_state_ctx (which is a structure that contains all the other state). But it's always accessed indirectly through the MP_STATE_VM / MP_STATE_MEM / MP_STATE_THREAD macros, which you could provide a different implementation for.

So you might be able to do something clever with thread-local storage to make this work where each hosting thread gets its own VM state (I imagine this would interact poorly if you tried to enable MicroPython threads, but this may not be important for you).

But yeah, this sort of sandboxing isn't really what MicroPython was designed for... but it would be great if you can make it work.