This enables warnings as errors and fixes all current errors, namely:
- reference to terms in the glossary must now be explicit (:term:)
- method overloads must not be declared as a separate method or must
use :noindex:
- 2 cases where `` should have been used instead of `
The WiPy machine.Timer class is very different to the esp8266 and esp32
implementations which are better candidates for a general Timer class. By
moving the WiPy Timer docs to a completely separate file, under a new name
machine.TimerWiPy, it gives a clean slate to define and write the docs for
a better, general machine.Timer class. This is with the aim of eventually
providing documentation that does not have conditional parts to it,
conditional on the port.
While the new docs are being defined it makes sense to keep the WiPy docs,
since they describe its behaviour. Once the new Timer behaviour is defined
the WiPy code can be changed to match it, and then the TimerWiPy docs would
be removed.
It's fair to just provide a link to all available modules, regardless of
the port. Most of the existing ports (unix, stm32, esp8266, esp32) share
most of the same set of modules anyway, so no need to maintain separate
lists for them. And there's a big discussion at the start of this index
about modules not being available on a given port.
For port-specific modules, they can also be listed unconditionally because
they have headings that explicitly state they are only available on certain
ports.
The old intro talked about "differences", but there were hardly any
sections describing differences, mostly MicroPython specific features.
On the other hand, we now have real "differences" chapter, though it's
mostly concerned with stdlib differences.
So, try to avoid confusion by changing wording and linking to the other
chapters and contrasting them with what is described in "MicroPython
language".
This introductions makes explicit the fact that whenever possible,
the documentation describes full MicroPython functionality, and arbitrary
functions/classes/modules may be missing in a paricular port or build.
Even the modules whose names don't start with "u" prefix are micro-ified
anyway, i.e. provide only subset of CPython's functionality (and sometimes
extensions to it). So, it doesn't make much sense to devide them by
criteria of having/not having "u" prefix.
David Lechner