> Please note that MicroPython is different from the Python that runs on a computer.
I once considered embedding MicroPython into a (software) product myself, but was dissuaded by the number of people who didn’t like being limited to a subset of Python.
Instead I used Lua, which is much less widely-known but is small enough to embed the whole language.
It’s interesting that Casio made the opposite decision. There’s definitely a trade-off between embedding MicroPython (“it’s the language you already know, but you need to learn which bits are missing”) and Lua (“you need to learn the language, but it’s the same everywhere”).
The "bits that are missing" relate to Python's standard library, which is huge. MicroPython has svelte versions of many of Python's standard library modules... Pick and choose what you need, given your specific context. MicroPython is pretty friendly in that respect.
FWIW, MicroPython, as a language, is a complete reimplementation of Python (and an amazing feat of engineering on the part of Damien and his collaborators).
> MicroPython, as a language, is a complete reimplementation of Python
But there are plenty of differences between MicroPython and CPython [0]. Many of them (listed under “Syntax”, “Core language” and “Builtin types”) relate to the language itself rather than the standard library.
Not to mention that the baseline for those lists is CPython 3.4 - MicroPython is also missing most of the new features of CPython 3.5 - 3.9.
> But there are plenty of differences between MicroPython and CPython
Are there any differences there that you'd consider significant? They are generally quite minor and usually have workarounds. Typically a difference is only introduced when additional memory (either adding complexity to the parser or in runtime use) is the consequence of absolute compatibility. They all seem like a reasonable trade-off.
> Not to mention that the baseline for those lists is CPython 3.4 - MicroPython is also missing most of the new features of CPython 3.5 - 3.9.
The baseline was 3.4 during development but more modern features have continued to be added, particularly if they can be shown to be implemented with low memory use. For example there is solid asyncio support (based on 3.8 [0]), the assignment operator has been implemented and, care has been taken to ignore type annotations correctly. fstring support is _almost_ there too (it ought to make it in to the next release).
The development team listens to requests for new language features so please raise a ticket (or comment on an existing one [1], [2]) to help prioritise upcoming features.
I don't see what the problem is, this is the kind of problems that you always bump into when not able to used the very latest and greatest of a programming language.
Specially one like Python that introduces breaking changes even across minor versions.
I once considered embedding MicroPython into a (software) product myself, but was dissuaded by the number of people who didn’t like being limited to a subset of Python.
Instead I used Lua, which is much less widely-known but is small enough to embed the whole language.
It’s interesting that Casio made the opposite decision. There’s definitely a trade-off between embedding MicroPython (“it’s the language you already know, but you need to learn which bits are missing”) and Lua (“you need to learn the language, but it’s the same everywhere”).