Josverl/micropython-stubs

Name 'MSB' is not defined when importing machine stub

jonathanfoster opened this issue · 8 comments

jonathanfoster commented

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.

micropython-stubs/publish/micropython-v1_19_1-esp32-stubs/umachine.py

Lines 932 to 953 in f7aa3c0

class SoftSPI:
"""
Construct a new software SPI object. Additional parameters must be
given, usually at least *sck*, *mosi* and *miso*, and these are used
to initialise the bus. See `SPI.init` for a description of the parameters.
"""
def __init__(self, baudrate=500000, *, polarity=0, phase=0, bits=8, firstbit=MSB, sck=None, mosi=None, miso=None) -> None:
""""""
...
def read(self, *args, **kwargs) -> Any:
...
def readinto(self, *args, **kwargs) -> Any:
...
def write(self, *args, **kwargs) -> Any:
...
LSB = 1 # type: int
MSB = 0 # type: int

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

Josverl commented

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

Josverl commented

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

jonathanfoster commented

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 commented

@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)

  • 👍1
jonathanfoster commented

@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 commented

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 commented

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 commented

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.

  • 👍1