This is my first post to the Python discuss, so please be gentle. I am a long-time MicroPython user and have been working on type stubs for MicroPython for the past few year, but I still enjoy learning from others each day.
The Python typing community has made significant strides in improving type-checking capabilities across various Python implementations. However, in my little corner of the Python-ecosystem the appetite for static type checking is held back by some limitations of the specification on how type-checkers can apply the available the platform characteristics, to type-stubs.
For MicroPython the challenge is to distinguishing MicroPython-specific code and differentiating type stubs for various ports. This is currently not possible, and as a result I currently maintain multiple stub packages - each for a separate port board where less than 20% of the stubs are actually different.
This proposal aims to introduce enhancements to type-checkers to better support MicroPython and its diverse platform values.
Current platform checks by type checkers are intentionally limited in the typing spec: Type checker directives â typing documentation
I would like to discus and brainstorm the following proposal with the community, and based on the feedback, I aim to create a PR with a proposal to update the typing spec.
Current Challenges
Currently, platform checks are underspecified in the typing spec: Type checker directives â typing documentation, which only mentions sys.platform
and sys.version_info
.
MicroPython utilizes over 12 additional sys.platform values, such as esp32, esp8266, mimxrt, nrf, renesas-ra, rp2, samd, stm32, unix, webassembly, windows, and zephyr. Currently, developers need to write long and repetitive boilerplate code to handle these platform checks, which is both cumbersome and error-prone.
For example:
if sys.platform == "esp32" or sys.platform == "esp8266" or sys.platform == "mimxrt" or sys.platform == "nrf" or sys.platform == "renesas-ra" or sys.platform == "rp2" or sys.platform == "samd" or sys.platform == "stm32" or sys.platform == "unix" or sys.platform == "webassembly" or sys.platform == "windows" or sys.platform == "zephyr" :
@overload
def sleep_ms(delay: float) -> None: ...
While MicroPython defines sys.implementation.name
as âmicropythonâ, a conditional such as if sys.implementation.name == "micropython":
does not work as expected with type-checkers as the use of this attribute is currently not part of the typing spec, and therefore not implemented. sys.implementation.name
can be used to distinguish not only micropython
, but circuitpython
, pypy
, cpython
, ironpython
and other implementations that may benefit for from this proposal.
sys.impementation.version
is also not supported in the typing spec, and therefore not implemented. MicroPython has a versioning scheme that is different from CPython, and, same as with CPython, it is important to be able to distinguish in the type-stubs between different versions of MicroPython. For example, the current version of MicroPython v1.25.0 is sys.version_info = (3,4,0)
and its sys.implementation.version = (1,25,0)
.
As the type_checkers will not run on micropython, the versions will need to be specified though configuration or commandline arguments.
Possible Solution
To address these challenges, I propose the following enhancements to the Python typing specification and type-checkers:
-
Support a limited number of additional attributes, such as
sys.implementation.name
in type checkers:When type-checkers correctly process
sys.implementation.name
, this will allow type stub authors to useif sys.implementation.name == "micropython":
orif sys.implementation.name == "pypy":
to simplify authoring of type stubs for these platforms.
my current thinking is that this should be limited to a small number of attributes, such assys.implementation.name
andsys.implementation.version
, to avoid overcomplicating the typing spec. -
Allow for additional checks:
Introduce support for more detailed sys.platform checks, allowing patterns such asif sys.platform in ('esp32', 'esp8266', 'mimxrt', 'nrf', 'renesas-ra', 'rp2', 'samd', 'stm32', 'unix', 'webassembly', 'windows', 'zephyr'):
. This would significantly reduce boilerplate code and improve readability.==
and!=
are already supportedin
andnot in
a set, list or tuple should be supported as well
Benefits
Implementing these enhancements will provide several benefits:
- Reduced Boilerplate Code: Developers will no longer need to write long and repetitive platform checks, leading to cleaner and more maintainable code.
- Improved Type-Checking Accuracy: Type-checkers will be able to accurately distinguish MicroPython, or PyPy specific code and differentiate type stubs for various ports, improving overall type-checking accuracy.
Related discussions :