Update micropython boards stubs to v1.24.1

[Josverl]

The new stubs contain additional type information for parameters and return types.
The depend on new functionality added in micropython-stdlib-stubs==1.24.1

esp32:

• micropython-esp32-stubs v1.24.1.post1
• micropython-esp32-esp32_generic-stubs v1.24.1.post1
• micropython-esp32-esp32_generic_c6-stubs v1.24.1.post1
• micropython-esp32-esp32_generic_s3-stubs v1.24.1.post1

rp2:

• micropython-rp2-stubs v1.24.1.post1
• micropython-rp2-arduino_nano_rp2040_connect-stubs v1.24.1.post1
• micropython-rp2-rpi_pico-stubs v1.24.1.post1
• micropython-rp2-rpi_pico2-stubs v1.24.1.post1
• micropython-rp2-rpi_pico_w-stubs v1.24.1.post1

samd:

• micropython-samd-stubs v1.24.1.post1
• micropython-samd-seeed_wio_terminal-stubs v1.24.1.post1

stm32:

• micropython-stm32-stubs v1.24.1.post1
• micropython-stm32-pybv11-stubs v1.24.1.post1

Relevant and related updates in the MicroPython-stubs repo

reference-stubs

The reference stubs themselves are created using the stubber tool to combine and merge infromation from the following sources.

• The v1.24.1 docstubs , generated from the micropython library documentation.
• PyBoardTypeshed created by Howard Lovatt
• PoC of type hints for the RP2 PIO assembler by Jos Verlinde
• Stubs for modules lacking documentation such as _threads and pars of hashlib and random
• A new _mpy_shed module has been created based on the _typeshed module. This allows the different micropython stub modules to refer to common types and constants, that are different than the standard CPython types and constants.

micropython-stdlib-stubs

The stubs for the async and uasyncio modules of earlier versions had many issues.
In this version, the stunb for asyncio are based on typeshed stdlib.asyncio stub, that has been tuned specifically for micropython by removing the features and functionality that is not available in MicroPython. However the Doc strings are taken from doc-stubs, to keep them in sync in line with the MicroPython Documentaion

For distribution the _mpy_shed module is added to the micropython-stdlib-stubs package.

Significant effort has been done to improve the ability for mypy to perform type checking on the micropython code,
while maintaining compatibility with the way the micropython documentation, is structured.
There are further improvement to be made, but this is a significant step forward for mypy users.

While parts of the stdlib modules are hand-edited, they can be updated by running the python build.py.
This functionality has not been merged into the stubber tool at this time.

---

This discussion was created from the release Update micropython boards stubs to v1.24.1.

[lukaskremla]

Hello,

I'm using your stubs in a fork of the PyCharm MicroPython plugin. They're bundled directly with the plugin so that they are always available.

I assume that the publish folder in this repository is the one with release-ready versions of the stubs and thus I take them from here. In the recent 1.24.1 update I noticed that some of the packages are missing asyncio/uasyncio stubs and they contain a removed.txt file with this description:

"modules removed to avoid incorrect merge effects:
asyncio"

Is this the right folder to get the stubs from?

[Josverl]

Somewhat the right folder.

Starting from v1.20 the stubs have a dependency on the micropython-stdlib-stubs distribution package.
With V1.24.1 I am reducing the overlap between these, to improve the ability of mypy to use the stubs.

If you install from pypi, the dependencies get installed, if you just copy, you miss out on the common essentials.

If you package them with your tool them I recommend:

• using uv/pip to install to a target folder during your build phase
• then include that folder in your distribution
• please also include a requirements-stubs.txt or project.toml with a reference to the stubs in the project folders your tool creates to allow me to track the usage of the stubs.
  This also gives traceability for the repo/project owners.

[Josverl]

It should be much simpler to install / update the stubs from pypi.
If you want to include an initial set,
It is perfectly fine to re-use and vendor the stubs, but please provide attribution in your tool.

[lukaskremla]

Thanks for the pointers. Getting the stubs directly from pip during the install phase is a really good idea. I'll look into how I can integrate the usage tracking, I didn't even think of this, so thanks for pointing me here.

Regarding licensing/attribution - The GitHub page is out of date, I didn't change things on it for several versions of the plugin. It has been written before I integrated your stubs and it wasn't changed since. I'm planning on adding drag and drop support and reworking the upload algorithm and also fine tuning pretty much all of the features, so I'm delaying the rewrite until I release the two major updates.

There is a copy of the MIT license from your repository in the stubs folder of my plugin, but I noticed it is missing from the licenses folder, and of course it is missing from the README.md. I apologize for that and I'll fix it.

Ever since the plugins uses your stubs you have been attributed in it, just not on GitHub. You're credited in the description of the plugin in the Jetbrains plugin marketplace and you're also credited in the plugin directly:

Screenshot of the plugin

The hyperlinks lead to your repository but please do let me know if you'd want them to point elsewhere.

Sorry for my oversights in attribution, this was by no means intentional and it will be fixed.

[Josverl]

No need to worry, I did find the license in the stubs folder so I know there is no bad intent whatsoever.

I'm happy to learn that you include the stubs, and make it simpler for people to use them.

I'd appreciate a reference to the stubs repo on the readme page or in an info page in the add-in or similar.

I was also thinking of adding a section to tools, add-ons and extensions, and would like to refer to your solution as well if that is OK with you.

[lukaskremla]

I have added the attribution to the repository's readme. And I'm not against the plugin being mentioned. I'd actually welcome that, so feel free to do so!