Name 'MSB' is not defined when importing machine stub

[jonathanfoster]

I'm patching machine.unique_id in a unit test and I get the following error:

../.venv/lib/python3.10/site-packages/machine.py:932: in <module>
    class SoftSPI:
../.venv/lib/python3.10/site-packages/machine.py:939: in SoftSPI
    def __init__(self, baudrate=500000, *, polarity=0, phase=0, bits=8, firstbit=MSB, sck=None, mosi=None, miso=None) -> None:
E   NameError: name 'MSB' is not defined

I double checked the machine stub and confirmed MSB is declared after being referenced in the init function. https://github.com/Josverl/micropython-stubs/blob/f7aa3c035869c33eb6224d5a6da2d6f520b97929/publish/micropython-v1_19_1-esp32-stubs/umachine.py#L932-L953

I'm using micropython-esp32-stubs 1.19.1.post5.

[Josverl]

That's not good, I'll take a look at detecting and fixing that

[Josverl]

But out of interest, are you patching the stub and is that failing , or does the ide report an error ?

[jonathanfoster]

No, this error occurs before I get a chance to patch. It occurs when machine is imported, the interpreter fails when parsing SoftSPI. I'm importing the entire machine module (e.g., import machine) in the code I'm testing and patching machine.unique_id in my test case.

[Josverl]

@jonathanfoster I have found a way to get these and other class literals sorted properly. I'll need to regenerate just about all stubs, but before I do that I did the v1.19.1 esp32 manually.

I published it to https://test.pypi.org/project/micropython-esp32-stubs/ install using pip install -i https://test.pypi.org/simple/ micropython-esp32-stubs

note that this includes a number of other changes as well. one of which changes would be to not include the .py files , but only the '.pyi' files.

would that work for you , or would you prefer to have both the .py and .pyi included ? ( or possibly an option)

[jonathanfoster]

@Josverl I need the .py files as well otherwise I'm unable to import MicroPython-specific modules like machine. Everything looks good though. I manually change the machine stub extension, set values for class variables, and I was able to run my test successfully.

[jonathanfoster]

Here's a unit test you can use to check for this issue in the future. It only includes the MicroPython-specific modules, but the same pattern can be applied to port-specific modules as well.

I ran it against micropython-esp32-stubs 1.19.1.post5 and all but btree and framebuf failed. Most failed because the .py files aren't there, but network failed due to AbstractNIC not being defined.

import unittest

class ImportTestCase(unittest.TestCase):
    def test_import_bluetooth(self):
        import bluetooth

    def test_import_btree(self):
        import btree

    def test_import_cryptolib(self):
        import cryptolib

    def test_import_framebuf(self):
        import framebuf

    def test_import_machine(self):
        import machine

    def test_import_micropython(self):
        import micropython

    def test_import_neopixel(self):
        import neopixel

    def test_import_network(self):
        import network

    def test_import_uctypes(self):
        import uctypes

    def test_import_wm8960(self):
        import WM8960

[Josverl]

When I try to package both the .pyi and .py files in the packet, poetry poetry failed to package and published the package to PYPI I'll still publishe the .py files to GitHub in the -merged folders so you should be able to grab them there.

Would that work for you ?

If not then the only way I can think of are

• Refactor each module to a folder with 3 or more files. foo.pyi will become folder foo with 2 files , init.py, init.pyi, or more for more comlex modules
  • Publish a 2nd package with only the .py files and tag that as a test/debug package

[jonathanfoster]

That works for me. Just pulled stubs/micropython-v1_19_1-esp32-merged/machine.py from the fix/literals branch and my test worked fine.