@Josverl

Thanks for the response.

The typing specification for Python mentions system and platform directives to select on sys.version and sys.platform

I think a similar feature for sys.implementation would allow you to select stubs specifically for micropython. The best that can be done today would be a sys.platform == 'pyboard' check, but I see that the micropython docs mention that this won't always work.

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 sys.platform.

@yangdanny97,
I think the last time I looked at that I was looking for a way to distinguish on the micropython version , and I did not pay attention to the sys.platform bit, so thanks for making me read that once again.

sys.platform
On this sense micropython's 'port' does indeed equate to sys.platform, so that will help if that indeed can be used in typing and validation of typing.
Currently there are some 19 different ports of micropython of which ~12 are most activivly used (esp32, esp8266, mimxrt, nrf, renesas-ra, rp2, samd, stm32, unix, webassembly, windows, zephyr) across these there are some 180 different boards, that we can choose to ignore to avoid too much complexity.
I can start with testing that.

version(s) : sys.version , sys.implementation.version
MicroPython's sys.implmentation.version (v1.24.1) is different from Python's version ( v3.4.0 )

Connected to MicroPython at COM4
Use Ctrl-] or Ctrl-x to exit this shell
sys.platform
'esp32'
>>> sys.implementation
(name='micropython', version=(1, 24, 1, ''), _machine='Generic ESP32 module with ESP32', _mpy=11014)
>>> sys.version
'3.4.0; MicroPython v1.24.1 on 2024-11-29'
>>> sys.version_info
(3, 4, 0)

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

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 sys.platform checks should work pretty well. Even if the runtime value differs, you can configure typecheckers to override the sys.platform value for typechecking purposes, so you could tell users to set their platform override to some specific value for micropython. https://mypy.readthedocs.io/en/stable/config_file.html#platform-configuration

It might be possible to add a typechecker directive to check sys.impementation.version (and maybe sys.implementation.name too). I'm not sure if anyone's floated that idea before, but one of us could post in the Python typing forum about it.

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 time.sleep_ms
The vast majority of port/platform specifics are contained in platform specific modules ( rp2, esp32, pyboard) and to a degree for the webassembly port/platform that is pyscript, but that separation is not 100% so using sys.platform could be useful

There are a few things that may hinder that though.
Typecheckers need simple checks
So will typecheckers be able to process in in expression such as

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 if sys.platform == "esp32" or sys.platform == "esp8266" ..., repeating for all platforms ?

Specifically in stdlib the logic seems to be assuming 3 platforms : linux, darwin, win32 , and only these three.
There are quite a few parts where the logic is like : if sys.platform not linux nor darwin , then it must be win32 and variations thereof.

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.

if sys.platform == "esp32" or sys.platform == "esp8266"

This would be better, I'm pretty sure mypy and pyright can both understand it, I don't think they can understand the in [...] syntax.

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:

name: mypy
on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-python@v2
      with:
        python-version: 3.8
    - run: pip install -r requirements-dev.txt
    - run: mypy <directory>

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

Awesome!