Python Type Annotations: Tooling/Gaps/Pain Points #2316
Replies: 2 comments 8 replies
-
|
There is an initial release for the webassembly port of MicroPython that including an initial stub for the https://github.com/Josverl/micropython-stubs/tree/main/publish/micropython-v1_24_1-webassembly-stubs That is based on the MicroPython specific tools I created, and parttly stubs created by The challenge is to create processes and tools to maintain consistent stubs and documentation without increasing the efforts, or complexity to do so for all maintainers. One thing that is missing specifically for micropython is that today it is not possible for type checkers to select on the MicroPython version, nor on the port (webassembly in this context) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the response. The typing specification for Python mentions system and platform directives to select on I think a similar feature for For the other thing you mentioned "port (webassembly in this context)", how are they usually identified? I would have thought that it would be a different value for |
Beta Was this translation helpful? Give feedback.
-
|
@yangdanny97,
version(s) : This is due to the fact that MicroPython implements Python 3.4 and some select features of Python 3.5 and above. See So it would be very useful when sys.impementation.version could be used in the same places as sys.version |
Beta Was this translation helpful? Give feedback.
-
|
When you're using typecheckers on these stubs, is micropython the python interpreter in that environment? Or are you writing and checking the code on a computer with cpython & then later using it on a microcontroller with micropython? If it's the latter, then It might be possible to add a typechecker directive to check |
Beta Was this translation helpful? Give feedback.
-
|
For MicroPython bare metal ports the type checking is done on the developers host / IDE or in CI using a 'fork' of _typeshed's stdlib that is tuned to remove functionality not available in MicroPython's stdlib, and add specifics such as There are a few things that may hinder that though. if sys.platform in ["esp32", " esp8266", " mimxrt", " nrf", " renesas-ra", " rp2", " samd", " stm32", " unix", " webassembly", " windows", " zephy"]:
@overload
def sleep_ms(delay: float) -> None: ...
@overload
def sleep_ms(delay: int) -> None: ...or should it be a longer but simpler Specifically in stdlib the logic seems to be assuming 3 platforms : linux, darwin, win32 , and only these three. It does not seem to cause any problems in a cursory QA testrun, but when we add 12+ platforms to a set of 3 current, then I want to think this though. |
Beta Was this translation helpful? Give feedback.
-
|
This would be better, I'm pretty sure mypy and pyright can both understand it, I don't think they can understand the |
Beta Was this translation helpful? Give feedback.
-
|
on a slightly different tack
|
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I think that could be pretty useful. Some sort of starter templates for github actions, pre-commit, and local configuration would be super nice to have. Mypy has a github action template, but it's more complicated than I'd expect: https://github.com/python/mypy/blob/master/action.yml The last time I wrote a mypy CI action, it looked like this: |
Beta Was this translation helpful? Give feedback.
-
|
I published a GH Action to allow typechecking of any MicroPython code by adding a stub package , and creating a pyproject.toml file in your repo. take your pick of pyright and/or mypy https://github.com/marketplace/actions/micropython_type_checking on:
push:
workflow_dispatch:
jobs:
CI:
runs-on: ubuntu-latest
name: MicroPython - CI
steps:
- uses: actions/checkout@v4
- name: Validate code
uses: josverl/mp_typecheck@latest
with:
typechecker: pyright, mypy
mp-stubs: micropython-rp2-pico_w-stubs |
Beta Was this translation helpful? Give feedback.
-
|
Awesome! |
Beta Was this translation helpful? Giv 8000 e feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, I'm following up from this post in the Python Typing forum, where this project was mentioned as a potential area that could benefit from typing investments.
I wasn't able to find any local typechecking configurations or CI workflows, though I see some past discussions around this, for example in #1173
I'd like to learn more about the current state of things, and any difficulties or pain points maintainers have encountered while trying to use Python types.
Is there tooling or automation that you wish you had, which would make it easier to add types or stubs for this codebase & keep the updated?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions