You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is kind of an "internal" issue because the ModuleAnalyzer is probably one of the most obscure and complex component of autodoc. Its purpose is to extract lines where methods, properties etc are defined and keep them so that autodoc and viewcode extensions can use them. In addition, I would like to keep this issue opened in order to track the tasks to do for the ModuleAnalyzer.
From what I see and know, here are the improvements that should (and sometimes must) be made:
Support subclassing of ModuleAnalyzer so that extensions can use it. Currently, it's very hard to actually subclass existing implementations of Sphinx components such as autodoc documenters because the implementation is not modular enough. While it could be a design choice for some cases (e.g., the couple writer-builder), it is very frustrating that "standalone" classes cannot be easily extendable. In particular, I would suggest a public API allowing the user to specify the module analyzer class to use.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
This issue is kind of an "internal" issue because the
ModuleAnalyzer
is probably one of the most obscure and complex component of autodoc. Its purpose is to extract lines where methods, properties etc are defined and keep them so that autodoc and viewcode extensions can use them. In addition, I would like to keep this issue opened in order to track the tasks to do for theModuleAnalyzer
.From what I see and know, here are the improvements that should (and sometimes must) be made:
if TYPE_CHECKING
guarded blocks in order to track imported types (see Sphinx 7.2 breaks Matplotlib's directive with Jax's arrays #11652 (comment)). This is also an alternative to [tracker] Improvement ofautodoc_type_aliases
#11687, or can be used in conjunction if the static analysis fails.ModuleAnalyzer
so that extensions can use it. Currently, it's very hard to actually subclass existing implementations of Sphinx components such as autodoc documenters because the implementation is not modular enough. While it could be a design choice for some cases (e.g., the couple writer-builder), it is very frustrating that "standalone" classes cannot be easily extendable. In particular, I would suggest a public API allowing the user to specify the module analyzer class to use.The text was updated successfully, but these errors were encountered: