-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
automodule
does not work with TYPE_CHECKING
guarded code
#13137
Comments
This is to be expected: I've not tested it, but you could try to adding
to your Sphinx |
I've tested it out a bit and it breaks on sphinx eources even, so it seems a more sophisticated solution is needed. Is it possible to interogate |
You could try to unhide your specific location only by something like
(Note: This is an idea, not tested because I don’t have a system to test at hand right now) |
The I was thinking of |
@LecrisUT does setting A |
@AA-Turner I supose you mean in reference to setting $ SPHINX_AUTODOC_RELOAD_MODULES=1 sphinx-build docs/ docs/_build
Running Sphinx v8.1.3
loading translations [en]... done
Extension error:
Could not import extension sphinx.builders.changes (exception: No module named 'typing_extensions') Installing |
I imagine this is as you use A |
Second attempt is trickier: $ SPHINX_AUTODOC_RELOAD_MODULES=1 sphinx-build docs/ docs/_build
Running Sphinx v8.1.3
loading translations [en]... done
Extension error:
Could not import extension sphinx.builders.epub3 (exception: cannot import name '_ReadableStream' from 'sphinx.util.typing' (/home/lecris/PycharmProjects/fmf-jinja/venv/lib/python3.13/site-packages/sphinx/util/typing.py)) |
Can you provide a full reproducer? It shouldn't be reloading internal modules (such as A |
The project I'm working on is at: https://github.com/LecrisUT/fmf-jinja/tree/fix/use-upstream-fmf That branch lacks the |
@AA-Turner I've seen the changelog entry for I also feel this is a bit inflexible because it's a global variable. Does it only affect the inspected module or may it propagate to modules that are imported in there as well? Even if it only affects the imports for autodoc, it affects all the documented modules. Extending the |
Preferably there would be a different approach. This method:
|
This doesn't make any sense, you are not supposed to do invasive changes to the py source for autodoc to work. (Many previous contributors have addressed this -there are workarounds available that get the job done, with some digging in the knowledge base they can be found- and none of them saw the need to change the
By all accounts this bug report is a duplicate. |
If there's nothing weird in the typing check branch then there's no reason to use the check at all. The snippet in the opening comment is a case in point. Why isn't it just: from typing import TypeAlias
ComplexType: TypeAlias = int | str
"""This has some documentation"""
def some_func(input: ComplexType) -> None:
"""Some function that uses the type alias""" That would work fine with type checking, autodoc and regular execution. I'd agree that if your code is complex enough to need a (Just an interested autodoc user.) |
One issue is with |
I strongly disagree! Typing imports under |
Randomly browsing the PEPs, PEP649 seems related to |
Describe the bug
I want to document
TypeAlias
variables which are typically guarded byif TYPE_CHECKING
or they might be defined in a stub file. The issue is that these members are not automatically added and indexed byautomodule
withmembers
. If I move the section to outside theTYPE_CHECKING
if-guard, then the member is being documented.How to Reproduce
Environment Information
Sphinx extensions
Additional context
No response
The text was updated successfully, but these errors were encountered: