micropython-lib
micropython-lib copied to clipboard
micropython
Typing module
The MicroPython compiler itself supports type annotations, so in principle the typing module will work. But there are no plans to port it. Feel free to try doing it yourself (you can start just by copying the CPython implementation, like some of the other modules here) and reporting about it here or on https://forum.micropython.org
Which Python version - if any - does Micropython track
As per the README in the top level of the main repo (https://github.com/micropython/micropython/blob/master/README.md) it's Python 3.4 with a bit of extra stuff (eg async/await keywords) from version 3.5.
Ah, thanks! I only looked inside the micropython-lib repo :)
So when porting, would it make sense to use the current 3.6 backport directly?
I could probably give it a stab this week. Would be useful to be able to typecheck micropython projects with mypy.
So when porting, would it make sense to use the current 3.6 backport directly?
Yes, because that will likely work and will be more up to date (eg with bug fixes) than earlier versions.
I just checked. The module makes a lot of use of the abc module which is not supported yet by micropython (and is probably not that easy to port).
It would probably be best to write dummy classes for all types. That way the typechecking could not be done on Micropython itself, but mypy running on regular python would probably work, with proper stubs.
Few comments:
- Writing a module from scratch for micropython-lib is almost always a better choice than to port (CPython stdlib is very bloated).
- If taking from CPython, taking a version from older CPython release (3.3, 3.4) is almost always a better choice, because with each release, modules in CPython become more and more bloated.
If taking from CPython, taking a version from older CPython release (3.3, 3.4) is almost always a better choice,
In this case, typing was introduced in 3.5 and has evolved a lot so 3.6 is probably a better implementation.
I saw the micropython-typing module. I can provide a hand. I'm also writing stub files for esp8266 port (1.9.2 currently). I'll release it as soon as I finish machine. Stub files I'm writing are using typing library. It'd be great if micropython would expose a fake typing module. Just to prevent import errors. Two cases are important from typing import something or import typing. I don't think micropython should support from typing import * or give an error to say "you need to install micropython-typing, which would be a minimal typing library.
I would really love to have a working typing module for Micropython. Sadly the CPython typing modules makes use of Metaclasses which are not supported by Micropython. I would prefer a lightweight utyping module that allows type-checking with Mypy over a fake module, though.
I had a closer look into CPythons typing module and think it would not fit the cause to make a complete port. It is rather complex and makes use of metaclasses which Micropython doesn't support. Also it would take a lot of unnecessary resources as static type-checkers like mypy only exist for CPython at the moment.
I think the workflow for static type-checking Micropython code at the moment looks more like this:
- add type annotations to the Micropython code
- Run CPythons mypy for static type-checking
- Upload the Micropython code to a controller
I think for such use-cases a fake typing module as proposed by @Cediddi would do the job. It allows to import typing classes like Any, Union or the cast() function in Micropython and use them as annotations. The type-checking can be done with mypy using CPythons typing module and its full functionality.
@stlehmann yes, I agree (as already suggested in my older comment). Stubs would be sufficient, you don't want to do typechecking on the target platform.
I added the fake modules in #297. It works for simple types like Any, Callable. But the generic types like List[int] or Dict[str, int] won' t work. This is because Micropython does not support the __class_getitem__(cls, key) special function that allows the creation of generic class objects. @dpgeorge would it be possible to add that feature?
I think a better way would be to avoid running the typing code, rather than shoe-horning a static annotations into the runtime. For now, simple if False: works.
I always use mpy-cross to compile py files before uploading to the board. Type annotations and stubs would help me develop my code faster, not run like a staticly typed program. Type annotations are ignored in runtime, they are just annotations.
Type annotations are ignored in runtime, they are just annotations.
Yes, but other typing code (like typing imports, newtypes, etc.) are not ignored. If no code is executed in the end, why would we need __class_getitem__?
I'm not sure about __class_getitem__ 's necessity but I think mpy-cross can ignore that operations.
If no code is executed in the end, why would we need class_getitem?
I also thought no code will get executed if no type-checking is done. But if you use a type-annotation like this:
myobj: List[int]
in the interpreter you will get a SyntaxError on execution.
Ok but with function annotations this works just fine:
def foo(bar: List[int]) -> None:
print("Hello")
This will execute without problems. Seems like type-annotations for simple objects is not supported by micropython.
Alright, I didn' t know that. Is there a reason why it is not implemented? Actually it seems like a little thing to do if function-annotations are implemented already.
@Cediddi A typing module with fake typing classes leads to working micropython code with type-annotations included. There would be no need to compile it to get rid of the annotations anymore.
I wonder if it is possible to write a typescript like transpiler for micropython, so that an extra module (~2000 lines) isn't needed.
G'day - reviving this dead issue 🧟
I wonder if it is possible to write a typescript like transpiler for micropython, so that an extra module (~2000 lines) isn't needed.
The dummy module provided by @stlehmann kind of gets the job done in significantly less code. It's not ideal, but I think a complete type-removing transpiler would be overkill.
Anyway I'm commenting because @stlehmann 's pull request was only ever merged into pfalcon's micropython-lib (now pycopy-lib). I can simply use pycopy-typing but it would be nice if it could be mirrored in micropython-typing to remove confusion (not sure if there would be licensing issues here).
Also, some of my code utilizes the typing_extensions module for which there appears to be no equivalent for micropython. Would you accept a pull request with said module implemented (in the same fashion as @stlehmann's contribution)?
Is it possible to at least have something like the TYPE_CHECKING property from the typing module so we can use autocompletion/typechecking in our code without the performance reduction and having to port over the entire typings library?
Is it possible to at least have something like the
TYPE_CHECKINGproperty from thetypingmodule so we can use autocompletion/typechecking in our code without the performance reduction and having to port over the entire typings library?
How about something like this?
try:
from typing import TYPE_CHECKING
except ImportError:
TYPE_CHECKING = False
if TYPE_CHECKING:
from typing import ...
Or this?
if getattr(globals(), '__annotations__'):
from typing import ...
@dlech hmm TYPE_CHECKING is one thing which I didn't include in the PR just made, any idea if this is commonly used?
A quick github search for TYPE_CHECKING in Python files show 210k hits vs 3.1 million for typing, so not super-common, I guess. But useful when you want to avoid unnecessary imports at runtime.
It's actually very important to have as it allows you to import things to satisfy type hinting that would otherwise cause circular dependencies. It's defined True by the type checking tools, should be False in the library
https://adamj.eu/tech/2021/05/13/python-type-hints-how-to-fix-circular-imports/
