This is an idea born out of a conversation I had earlier today at EuroRust.
Rust has a lot of success in the embedded space. There is also MicroPython to bring Python to these tiny devices (useful for certain applications). This begs the question, can PyO3 support MicroPython, should it, and who would benefit from it?
If you think the answer is that PyO3 should support MicroPython and you'd be interested in making it happen, please get involved! I think before we definitely commit to adding support to PyO3 we'd need to understand how much complexity it would add for us as maintainers, what features we would be able to support, and how we can test it in CI.
Some observations:
It looks like MicroPython has a completely different C API, with unique restrictions. See https://docs.micropython.org/en/latest/develop/natmod.html. If it makes sense, we could write a shim in pyo3-ffi to keep the complexity there, but I haven't looked in detail at the API, maybe it's too different.
It looks like packaging for MicroPython is completely different to PyPI wheel packaging (again see the above link). Probably maturin would need to consider adding some support.
#![no_std] is probably useful for these targets. PyO3 could add a #![no_std] feature regardless of whether we decide to accept MicroPython support. I don't think it would be too bad, just needs someone who wants it to investigate it.
This is an idea born out of a conversation I had earlier today at EuroRust.
Rust has a lot of success in the embedded space. There is also MicroPython to bring Python to these tiny devices (useful for certain applications). This begs the question, can PyO3 support MicroPython, should it, and who would benefit from it?
If you think the answer is that PyO3 should support MicroPython and you'd be interested in making it happen, please get involved! I think before we definitely commit to adding support to PyO3 we'd need to understand how much complexity it would add for us as maintainers, what features we would be able to support, and how we can test it in CI.
Some observations:
pyo3-ffi
to keep the complexity there, but I haven't looked in detail at the API, maybe it's too different.maturin
would need to consider adding some support.#![no_std]
is probably useful for these targets. PyO3 could add a#![no_std]
feature regardless of whether we decide to acceptMicroPython
support. I don't think it would be too bad, just needs someone who wants it to investigate it.