Mypy extension
nstarman opened this issue · 5 comments
Thanks for the useful library!
In a different discussion (#28) I suggested that lazy_loader package a mypy extension to allow mypy to understand lazy_loader's dynamic __all__, without the need for the .pyi stub file, which led to #36. Since this Issue is really upstream in the AST, maybe the mypy extension is the better solution. I made some progress on the extension in https://github.com/nstarman/lazy_loader/tree/mypy_plugin, but I ran into some difficulties I didn't understand since I'm not overly familiar with the internals of mypy.
Why is this necessary? Stub files in namespace packages don't work as needed (see #36). But normal py files do. A mypy extension for lazy_loader would allow static type checking in namespace packages.
Concerns lifted from #36: (1) not all users employ the generated __all__ (2) stubs should address this issue—they just don't support importing from other packages, but that functionality could potentially be added to the stubs loader.
Any solution that works 😆!
The place to focus our attention may be the stubs loader then, to address importing from other modules. Perhaps @tlambert03 has thoughts on that.
my experience with mypy plugins has been pretty painful, and also doesn't cover a number of typing use cases (such as an IDE using pyright, etc...), so i've generally tried to avoid it. from a typing perspective, lazy_loader really just isn't ideal.
__all__ and .pyi files (or if TYPE_CHECKING) clauses are already the established ways to indicate names to static type checkers, creating a mypy extension to work around the need to provide __all__ kinda feels like a lot of work just to avoid using the standard conventions
Since we have workarounds (.pyi and if TYPE_CHECKING), I'm going to close for now since it's not clear how a mypy plugin will be implemented.