mirrors
/
micropython
mirror of https://github.com/micropython/micropython.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

descriptors: typo fix not -> now

Paul Sokolovsky 2015-09-03 19:25:56 +03:00
parent d8fabbeb05
commit 21b64debd9
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Differences.md

@ -9,7 +9,7 @@ MicroPython is intended for constrained environments, in particular, microcontro
1. MicroPython does not ship with an extensive standard library of modules. It's not possible and does not make sense, to provide the complete CPython3 library. Many modules are not usable or useful in the context of embedded systems, and there is not enough memory to deploy the entire library on small devices. So MicroPython takes the minimalist approach - only core datatypes (plus modules specific to particular hardware) are included with the interpreter, and all the rest is left as 3rd-party dependencies for particular user applications. The [micropython-lib](https://github.com/micropython/micropython-lib) project provides a non-monolithic standard library for MicroPython ([forum](http://forum.micropython.org/viewtopic.php?f=5&t=70))
1. Unlike CPython3, which uses reference-counting, MicroPython uses garbage collection as the primary means of memory management.
1. MicroPython does not implement complete CPython object data model, but only a subset of it. Advanced usages of multiple inheritance, ``__new__`` method may not work. Method resolution order is different (#525). Metaclasses are not supported (at least yet).
1. MicroPython design is not based around descriptor objects. So far, we were able to implement all native Python features (like properties) without explicit descriptors. Descriptors are considered "overdynamic" feature, and conflicts with the aim of being fast and efficient. However, simplified support for descriptors is not implemented, as an opt-in feature.
1. MicroPython design is not based around descriptor objects. So far, we were able to implement all native Python features (like properties) without explicit descriptors. Descriptors are considered "overdynamic" feature, and conflicts with the aim of being fast and efficient. However, simplified support for descriptors is now implemented, as an opt-in feature.
1. By virtue of being "micro", MicroPython implements only subset of functionality and parameters of particular functions and classes. Each specific issue may be treated as "implementation difference" and resolved, but there unlikely will ever be 100% coverage of CPython features.
1. By virtue of being "micro", MicroPython supports only minimal subset of introspection and reflection features (such as object names, docstrings, etc.). Each specific feature may be treated as "implementation difference" and resolved, but there unlikely will ever be 100% coverage of CPython features.
1. print() function does not check for recursive data structures in the same way CPython does. There's however checks for stack usage, so printing recursive data structure won't lead to crash due to stack overflow. Note that it's possible to implement more CPython-like handling of recursive data structures on the Python application level. Do this by writing a function which keeps the history of each object visited, and override the builtin print() with your custom function. Such an implementation may of course use a lot of memory, which is why it's not implemented at the MicroPython level.