Specify `TYPE_CHECKING = False` without typing import

AA-Turner · March 22, 2025, 3:43am

A quick search on GitHub for TYPE_CHECKING = True (excluding Sphinx’s autodoc) shows c. 16 results:

Six seem related to building docs
Six seem to be used in tests
Two seem to be homework projects
One is in support of a runtime type checker
One is for getting module globals in a TYPE_CHECKING block

To be clear, this is extremely minimal use given the corpus of all code on GitHub (unless something is wrong with my search query!).

A

Jos_Verlinde · March 25, 2025, 6:42pm

There is a limited implementation of typing for MicroPython but it’s not part of the standard builds.

It would be good to have a standard solution for cases where every byte counts.

github.com/Josverl/micropython-stubs

mip%2Freadme.md

main

# MicroPython's `typing.mpy` module

Why you may need typing.[m]py or typing_extensions.[m]py.

When making use of static typing in Python or MicroPython, you often end up using types that are defined in the CPython typing module.
As Python static typing is 'optimized out' when the source is compiled to byte-code and then to machine-code, there is virtually no runtime overhead.

However there is one remaining issue, and this is with the `import typing` or `from typing import ...`  
If you try to run an fully typed MicroPython module or script on a MCU, you will get an error like this:

```python
>>> import example
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "example.py", line 2, in <module>
ImportError: no module named 'typing'
```
A solution is to add a minimalistic `typing.py` file to the project, and when your module or script is executed on the MCU, that will be used in place of the CPython typing module.

This file has been truncated. show original

ehomrich · March 26, 2025, 3:04pm

Regarding import times, currently (read, 3.13) typing has a module-level __getattr__ to generate some aliases on-the-fly.

Wouldn’t moving the special forms implementations to an “internal” module, something like _typing.py or _typing_internals.py, and using typing’s __getattr__ to get them from that module help reduce load times? Or would module resolution merge everything anyway?

Jelle · March 26, 2025, 4:31pm

I think that would make sense if there is one thing (or a few things) in typing.py that are both slow to create and rarely used. But I’m not sure that’s true; it’s slow mostly because there’s a lot of stuff in there, not because any particular thing is slow. However, maybe detailed profiling will show that I’m wrong there, so I’d love for someone to take a detailed look and try to find ways to make typing.py faster to execute.

mikeshardmind · March 26, 2025, 5:05pm

probably not. The moment someone has a module level import of from typing import SomeAlias the __getattr__ will be invoked. For this to have any benefit, you’d need import typing as t and then use of t.SomeAlias only in places where evaluation of the attribute access is deferred, such as type alias statements or annotations (3.13 and earlier with a future import, 3.14 forward with 649)

This could still be done, but it would require adoption across “foundational libraries” to make it likely that users dont end up eagerly importing anyhow. It also rules out use of typing decorators.
You can see this post for details on the current limitations of runtime deferral of typing.

Something that would improve performance here is to remove all the metaprogramming tricks going on in that file and expand it in source code instead. This reduces the amount of things that need executing at import time, but that’s not free either, it has costs on development in some form or other, and would probably make a codegen script appealing (even if it’s run manually and results checked in).