Handle C-modules that are extended by a frozen module (ESP32 - machine.py)

[Josverl]

Some modules are built of a combination of :

• C
• Frozen .pyhyon files.

Stubber does not handle this well, not at all in fact.

The first encounter is:

• https://github.com/micropython/micropython/blob/master/ports/esp32/modules/machine.py
• introduced in : micropython/micropython@3276559

This was unexpected - and breaks the stub merge/collation by overwriting machine.pyi with a partial implementation

breakdown

• manifest contains partial/complementary machine.py module
• this is saved as a frozen module that should be included
• it is then turned into a stub ( mypy stubgen )
• that stub is then enriched with the reference stub classes and type info - which ironically made it harder to detect ( stubber enrich )
• during the final build proces the partial frozen.machine.pyi overwrote the intended machine.pyi

Current workaround :

skip copying machine.pyi from the frozen stubs altogether

STUBS_COPY_FILTER = {
StubSource.FROZEN: [
"machine", # esp32.frozen.machine.py is used to implement PCNT
# https://github.com/micropython/micropython/blob/master/ports/esp32/modules/machine.py
]

Future

• is this a common pattern with more internal + frozen modules ?
• limit the enhancement of the fozen.machine.py
• append the additional methods & classes
• add documentation for these classes
• add the classes to the reference ?
• add @mp_availability(port="esp32")