c737cde947
Anywhere a module is mentioned, use its "non-u" name for consistency. The "import module" vs "import umodule" is something of a FAQ, and this commit intends to help clear that up. As a first approximation MicroPython is Python, and so imports should work the same as Python and use the same name, to a first approximation. The u-version of a module is a detail that can be learned later on, when the user wants to understand more and have finer control over importing. Existing Python code should just work, as much as it is possible to do that within the constraints of embedded systems, and the MicroPython documentation should match the idiomatic way to write Python code. With universal weak links for modules (via MICROPY_MODULE_WEAK_LINKS) users can consistently use "import foo" across all ports (with the exception of the minimal ports). And the ability to override/extend via "foo.py" continues to work well. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
30 lines
802 B
ReStructuredText
30 lines
802 B
ReStructuredText
:mod:`array` -- arrays of numeric data
|
|
=======================================
|
|
|
|
.. module:: array
|
|
:synopsis: efficient arrays of numeric data
|
|
|
|
|see_cpython_module| :mod:`cpython:array`.
|
|
|
|
Supported format codes: ``b``, ``B``, ``h``, ``H``, ``i``, ``I``, ``l``,
|
|
``L``, ``q``, ``Q``, ``f``, ``d`` (the latter 2 depending on the
|
|
floating-point support).
|
|
|
|
Classes
|
|
-------
|
|
|
|
.. class:: array(typecode, [iterable])
|
|
|
|
Create array with elements of given type. Initial contents of the
|
|
array are given by an `iterable`. If it is not provided, an empty
|
|
array is created.
|
|
|
|
.. method:: append(val)
|
|
|
|
Append new element ``val`` to the end of array, growing it.
|
|
|
|
.. method:: extend(iterable)
|
|
|
|
Append new elements as contained in `iterable` to the end of
|
|
array, growing it.
|