|
|
|
@ -191,34 +191,27 @@ The following libraries are specific to the Zephyr port.
|
|
|
|
|
Extending built-in libraries from Python
|
|
|
|
|
----------------------------------------
|
|
|
|
|
|
|
|
|
|
Many built-in modules are actually named ``umodule`` rather than ``module``, but
|
|
|
|
|
MicroPython will alias any module prefixed with a ``u`` to the non-``u``
|
|
|
|
|
version. This means that, for example, ``import time`` will first attempt to
|
|
|
|
|
resolve from the filesystem, and then failing that will fall back to the
|
|
|
|
|
built-in ``utime``. On the other hand, ``import utime`` will always go directly
|
|
|
|
|
to the built-in.
|
|
|
|
|
A subset of the built-in modules are able to be extended by Python code by
|
|
|
|
|
providing a module of the same name in the filesystem. This extensibility
|
|
|
|
|
applies to the following Python standard library modules which are built-in to
|
|
|
|
|
the firmware: ``array``, ``binascii``, ``collections``, ``errno``, ``hashlib``,
|
|
|
|
|
``heapq``, ``io``, ``json``, ``os``, ``platform``, ``random``, ``re``,
|
|
|
|
|
``select``, ``socket``, ``ssl``, ``struct``, ``time`` ``zlib``, as well as the
|
|
|
|
|
MicroPython-specific ``machine`` module. All other built-in modules cannot be
|
|
|
|
|
extended from the filesystem.
|
|
|
|
|
|
|
|
|
|
This allows the user to provide an extended implementation of a built-in library
|
|
|
|
|
(perhaps to provide additional CPython compatibility or missing functionality).
|
|
|
|
|
The user-provided module (in ``module.py``) can still use the built-in
|
|
|
|
|
functionality by importing ``umodule`` directly (e.g. typically an extension
|
|
|
|
|
module ``time.py`` will do ``from utime import *``). This is used extensively
|
|
|
|
|
in :term:`micropython-lib`. See :ref:`packages` for more information.
|
|
|
|
|
This is used extensively in :term:`micropython-lib`, see :ref:`packages` for
|
|
|
|
|
more information. The filesystem module will typically do a wildcard import of
|
|
|
|
|
the built-in module in order to inherit all the globals (classes, functions and
|
|
|
|
|
variables) from the built-in.
|
|
|
|
|
|
|
|
|
|
This extensibility applies to the following Python standard library modules
|
|
|
|
|
which are built-in to the firmware: ``array``, ``binascii``, ``collections``,
|
|
|
|
|
``errno``, ``hashlib``, ``heapq``, ``io``, ``json``, ``os``, ``platform``,
|
|
|
|
|
``random``, ``re``, ``select``, ``socket``, ``ssl``, ``struct``, ``sys``,
|
|
|
|
|
``time``, ``zlib``, as well as the MicroPython-specific libraries: ``bluepy``,
|
|
|
|
|
``bluetooth``, ``machine``, ``timeq``, ``websocket``. All other built-in
|
|
|
|
|
modules cannot be extended from the filesystem.
|
|
|
|
|
|
|
|
|
|
*Other than when you specifically want to force the use of the built-in module,
|
|
|
|
|
we recommend always using* ``import module`` *rather than* ``import umodule``.
|
|
|
|
|
|
|
|
|
|
**Note:** In MicroPython v1.21.0 and higher, it is now possible to force an
|
|
|
|
|
import of the built-in module by clearing ``sys.path`` during the import. For
|
|
|
|
|
example, in ``time.py``, you can write::
|
|
|
|
|
In MicroPython v1.21.0 and higher, to prevent the filesystem module from
|
|
|
|
|
importing itself, it can force an import of the built-in module it by
|
|
|
|
|
temporarily clearing ``sys.path`` during the import. For example, to extend the
|
|
|
|
|
``time`` module from Python, a file named ``time.py`` on the filesystem would
|
|
|
|
|
do the following::
|
|
|
|
|
|
|
|
|
|
_path = sys.path
|
|
|
|
|
sys.path = ()
|
|
|
|
@ -228,6 +221,25 @@ example, in ``time.py``, you can write::
|
|
|
|
|
sys.path = _path
|
|
|
|
|
del _path
|
|
|
|
|
|
|
|
|
|
This is now the preferred way (instead of ``from utime import *``), as the
|
|
|
|
|
``u``-prefix will be removed from the names of built-in modules in a future
|
|
|
|
|
version of MicroPython.
|
|
|
|
|
def extra_method():
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
The result is that ``time.py`` contains all the globals of the built-in ``time``
|
|
|
|
|
module, but adds ``extra_method``.
|
|
|
|
|
|
|
|
|
|
In earlier versions of MicroPython, you can force an import of a built-in module
|
|
|
|
|
by appending a ``u`` to the start of its name. For example, ``import utime``
|
|
|
|
|
instead of ``import time``. For example, ``time.py`` on the filesystem could
|
|
|
|
|
look like::
|
|
|
|
|
|
|
|
|
|
from utime import *
|
|
|
|
|
|
|
|
|
|
def extra_method():
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
This way is still supported, but the ``sys.path`` method described above is now
|
|
|
|
|
preferred as the ``u``-prefix will be removed from the names of built-in
|
|
|
|
|
modules in a future version of MicroPython.
|
|
|
|
|
|
|
|
|
|
*Other than when it specifically needs to force the use of the built-in module,
|
|
|
|
|
code should always use* ``import module`` *rather than* ``import umodule``.
|
|
|
|
|