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

Note down the state of Unicode support, and minorly clarify terminology in top paragraph

Chris Angelico 2014-06-09 17:13:47 -07:00
parent 22f9a5c908
commit b56d659b7d
1 changed files with 3 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
Differences.md

@ -1,4 +1,4 @@
This page is a proof-of-concept effort to document the differences between CPython3 (considered to be a reference implementation of the Python3 language) and MicroPython. It classifies differences into 3 categories, each category having a different status regarding the possibility that items belonging to it will change.
This page is a proof-of-concept effort to document the differences between CPython3 (the most popular and most-used implementation of the Python3 language) and MicroPython. It classifies differences into 3 categories, each category having a different status regarding the possibility that items belonging to it will change.
## Differences By Design
MicroPython is intended for constrained environments, in particular, microcontrollers, which have orders of magnitude less performance and memory than "desktop" systems on which CPython3 runs. This means that MicroPython must be designed with this constrained environment in mind, leaving out features which simply won't fit, or won't scale, with target systems. "By design" differences are unlikely to change.
@ -13,13 +13,14 @@ MicroPython is intended for constrained environments, in particular, microcontro
## Implementation Differences
Some features don't cater for constrained systems, and at the same time are not easy to implement efficiently, or at all. Such features are known as "implementation differences" and some of them are potentially the subject for future development (after corresponding discussion and consideration). Note that many of them would affect the size and performance of any given MicroPython implementation, so sometimes not implementing a specific feature is identified by MicroPython's target usage.
1. No unicode support is actually implemented. Python3 calls for strict difference between ``str`` and ``bytes`` data types (unlike Python2, which has neutral unified data type for strings and binary data, and separates out unicode data type). MicroPython faithfully implements ``str``/``bytes`` separation, but currently, underlying ``str`` implementation is the same as ``bytes``. This means strings in MicroPython are not unicode, but 8-bit characters (fully binary-clean).
1. The only source code encoding supported is UTF-8, and currently, non-ASCII identifiers are not guaranteed to work correctly. Strings containing Unicode escapes in the \xNN, \uNNNN, and \U000NNNNN forms are fully supported; \N{...} is not supported.
1. Object finalization (``__del__()`` method) is supported for builtin types, but not yet user classes. This is tracked by [#245](//github.com/micropython/micropython/issues/245).
1. Subclassing of builtin types is partially implemented, but there may be various differences and compatibility issues with CPython. [#401](//github.com/micropython/micropython/issues/401)
## Known Issues
Known issues are essentially bugs, misfeatures, and omissions considered such, and scheduled to be fixed. So, ideally any entry here should be accompanied by bug ticket reference. But note that these known issues will have different priorities, especially within wider development process. So if you are actually affected by some issue, please add details of your case to the ticket (or open it if does not yet exist) to help planning. Submitting patches is even more productive. (Please note that the list of not implemented modules/classes include only those which are considered very important to implement; per the above, MicroPython does not provide full standard library in general.)
1. Non-ASCII strings do not yet fully work. [#657](//github.com/micropython/micropython/issues/657)
1. Some functions don't perform argument checking well enough, which potentially may lead to crash if wrong argument types are passed.
1. Some functions use ``assert()`` for argument checking, which will lead to crash if wrong argument types are passed/erroneous conditions are faced. This should be replaced with Python exception raising.
1. It's not possible to override builtin functions in a general way. So far - no "builtins" module is implemented, so any overrides work within the current module only.