Interoperability between micropython and CPython?

[torwag]

Hi,

I started to read about USB-host functionality etc. and was wondering how micropython (or a micropython module) will expose this (and other functions) to the user. I'm pretty sure it would be possible to write a library and a python module to do that, thus you would need to call pyboard.usb.<whatever> or something similar. However, micropython tries to be as close to standard python as possible and if I understand this right not just in terms of the language but also in a way ordinary users expect to work with python. A lot of effort is being put by the python community to make sure there is a single module (e.g. sys, os, etc.) independent working of the underlying architecture (and OS). For this very basic modules, I assume/know micropython will have an equivalent. However, where to stop?

E.g. going back to my initial task, should micropython have a version of pyUSB for USB support? Or would it be more realistic to create a set of micropython specific modules e.g. for USB? Esp. if one takes into account that there will be different uC architectures in the future.
My question is, where to draw a line? What should work the same way like people know it from a PC (same namespace, same function-calls, returns, etc.) and what should be provided by a micropython/board specific module?

It goes a bit along the line, would/should it be possible to write a program on a PC (maybe with micropython installed) and being able to copy it over to micropython running on a microcontroller without further changes? If it should be possible, how to deal with differences between micropython and python for certain modules, how to deal with low-level resp. board specific calls testing the program on a PC (do we want a pyboard emulator)?
As an example take again USB. Should we be able to use the same python code on a PC as well as on the pyboard since both come with USB host and slave functionality?

[pfalcon]

Well, for me the answer is clear - uPy should support standard Python interfaces.That's, when they are proven for good domain coverage and unbloatness. Where existing Python solutions fail, uPy should come with better solutions - but not for itself, but for the benefit of wide Python community.

And I personally don't see any big differences with how "board" and "desktop" work - from the level of abstraction of Python. Actually, even from the level of C++, looking from C level they're of course different, ergo: don't look at stuff from C level, that's useful language to teach students machine-independent assembler, but that's all.

And I actually have been spending quite a lot of discussion with "bare-metal" folks trying to get them think "outside the board". For example, there was long discussion on which model to use for GPIO addressing, then here's this: https://github.com/micropython/micropython/issues/478 , and latest incarnation is here: https://github.com/micropython/micropython/pull/512 . Results vary, mildly speaking .