MicroPython does not support all of the Python standard library. The excluded modules are inappropriate for use with the embedded controller. Some modules cannot be implemented by the microcontroller due to high memory consumption (such as sqlite3) or lack of required hardware functionality (such as multiprocessing). A complete list of Python standard libraries can be found here: Python 3.4 Standard lib
There are some differences between CPython3 (the reference implementation of the Python3 language) and MicroPython. Differences fall into three categories. Each category has a different status regarding the possibility that the items classified in each category will change.
MicroPython is intended for highly constrained environments, especially microcontrollers that are more performance and memory constrained than the "desktop" system on which CPython3 runs. In short, MicroPython must be designed with this constrained environment in mind, excluding features that don't fit or scale to the target system. It is unlikely that you will change the "design" difference.
MicroPython does not come with an extensive standard library of modules. It is impossible and unreasonable to provide a complete CPython3 library. Many modules are neither available nor useful in the context of embedded systems. There is not enough memory to deploy the entire library on a small device. Therefore, MicroPython takes a minimal approach. Only core data types (plus modules specific to a particular hardware) are included in the interpreter, and the rest are third party dependent on a particular user application. The micropython-lib project provides a non-monolithic standard library for MicroPython (Forum. viewtopic.php? f = 5 & t = 70)))
Unlike CPython3, which uses reference counting, MicroPython uses garbage collection as its primary means of memory management.
MicroPython does not implement the complete CPython object data model, but only a subset of it. The __new__ method, which is an advanced usage of multiple inheritance, may not work. The method resolution order is different (# 525). Metaclasses are not (at least not yet) supported.
MicroPython's design is not based on descriptor objects. So far, I've implemented all the native Python features (including properties), except for explicit descriptors. Descriptors are considered "too dynamic" features, which contradicts the goal of being fast and efficient. However, as an opt-in feature, we have implemented simplified support for descriptors.
MicroPython is "micro", so it implements only a subset of the parameters of a function or specific function or class. Each particular issue may be treated as an "implementation difference" and resolved, but it is unlikely to cover 100% of CPython's functionality.
Because MicroPython is "micro", it supports only a minimal subset of introspection and reflection features (object names, document strings, etc.). Each particular feature is treated as an implementation difference and may be resolved, but it is unlikely to cover 100% of CPython's features.
The print () function does not check the recursive data structures that CPython handles. However, because it checks stack usage, displaying recursive data structures does not crash on stack overflow. It is possible to implement CPython-like processing for recursive data structures at the Python application level. Create a function that keeps a history of each referenced object and override the built-in print () with a custom function. Such implementations, of course, can use a lot of memory. Therefore, it is not implemented at the MicroPython level.
MicroPython optimizes the handling of local variables and does not record or provide introspection information. For example, locals () has no entries for local variables.
Some features may not be compatible with constrained systems or may not be easy to implement efficiently. Such features are referred to as "implementation differences" and some may be subject to future development (after corresponding discussion and consideration). Many of the "implementation differences" affect the size and performance of the MicroPython implementation, so some MicroPython targets may not implement a particular feature.
Unicode support is in progress. It is based on an internal representation using UTF-8. Full support for strings containing Unicode escapes in the \ xNN, \ uNNNN, and \ U000NNNNN formats. \ N {...} is not supported. # 695.
Object finalization (__del__ () method) is not supported in the built-in type, but it is supported in the user class. This is supported by # 245.
Built-in subclassing is partially implemented, but has various differences and compatibility issues with CPython. # 401
It does not support buffered I / O streams (io.TextIOWrapper and its superclass).
The ʻasync def keyword is simply implemented as follows: There is no separate "coroutine" object type, and the ʻasync def appears in the function body as "yield" or "yield from". Just define a generator function that doesn't require anything about it. ʻAsync def` Does not detect or disallow the use of "yield" or "yield from" in the function.
ʻasync with` should be equivalent to the description in PEP492.
ʻasync for` should be equivalent to the description in PEP492.
There is no support for "Future-like objects" in the __await__ method. await is only available on coroutines and generators (not "Future-like objects"). It's also just syntactic sugar for "yield from", accepting iterables and iterators, which CPython doesn't allow.
Support for instance __dict __ is optional (disabled in many ports) and is read-only, so foo .__ dict __ ['bar'] = 23 or foo .__ dict __. update ({'bar': 23}) does not work. # 1757, # 2139
Known issues are essentially considered to be bugs or incorrect features and will be fixed. Therefore, you should ideally also refer to bug tickets for what is written here. However, note that these known issues have different priorities, especially within a wide range of development processes. Therefore, if you are actually affected by the issue, please add the case details to your ticket (register if the ticket does not already exist) to help reflect it in your plan. Sending patches is even more productive. (Note that the list of unimplemented modules / classes contains only those that are considered very important to implement; as mentioned earlier, MicroPython provides a general full standard library. Absent.
Some functions do not check their arguments sufficiently, so they may crash if the wrong argument type is passed. ~~
Some features use ʻassert ()` to check arguments. Wrong argument type passed → Faced with wrong conditions leads to crash. Replace this with a Python exception.
~~ Built-in functions cannot be overridden in the usual way. So far, the "builtins" module has not been implemented, so all overrides will only work within the current module. # 959 ~~
Persistent bytecode support (.pyc analog) is in beta.
The ~~ print () function does not use the Python stream infrastructure, but uses the underlying C printf () function directly. That is, overriding sys.stdout does not affect print (). # 209 ~~
Currently, sys.stdin, sys.stdout, and sys.stderr cannot be overridden (for efficiency, they are stored in read-only memory).
~~ The more advanced use of package / module imports has not yet been fully implemented. # 298 ~~
~~ Exception handling by generator is not fully implemented. ~~ (Some small details may still need to be addressed.) # 243
str.format () may miss advanced / ambiguous features (But almost fully implemented). \ # 407, # 574
The ~~% string format operator may have missed more advanced features ~~ # 403, [# 574] ](Https://github.com/micropython/micropython/issues/574)
The struct module implementation (named ʻustruct) should have all the basic functionality ~~, but some syntactic sugar (like repeating type strings) No ~~. Renamed to the full struct` feature that works at the Python level
Instead of the re module, the minimized" ure "module is a subset of the functionality provided by re. micropython-lib provides a complete implementation based on the "PCRE" engine for "unix" porting # 13
So far there is only the beginning of the ʻio` module and class hierarchy.
The collections.deque class is not implemented.
~~ memoryview object is not implemented. ~~
Container slice allocation / deletion is only partially implemented. # 509
17.3 Argument slicing is only partially implemented.
~~ Keywords and keyword-only arguments require more work. ~~ # 466, # 524
Only basic support is available for the __new__ method \ # 606, [# 622](https://github. com / micropython / micropython / issues / 622)
~~ long int bit operations are only partially implemented (X & 0xffffffff idiom for the task of casting signed 32-bit values unsigned). ~~ # 1810
Recommended Posts