Skip to content
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

Incorrect display of function/class argument types in documentation. #262

Open
Tracked by #324
j-emberton opened this issue Jul 17, 2024 · 9 comments · May be fixed by #319
Open
Tracked by #324

Incorrect display of function/class argument types in documentation. #262

j-emberton opened this issue Jul 17, 2024 · 9 comments · May be fixed by #319
Assignees
Labels
bug Something isn't working

Comments

@j-emberton
Copy link
Collaborator

Describe the bug
Incorrect display of function/class argument types in documentation.

Expected behavior
I would expect to just see a display of arguments with a simple type e.g. my function(arg1: NDArray)

Screenshots
Screenshot 2024-07-17 at 15 07 25

Desktop (please complete the following information):

  • OS: MacOS 14
  • Safari

Additional context
Add any other context about the problem here.

@j-emberton j-emberton added the bug Something isn't working label Jul 17, 2024
@j-emberton j-emberton self-assigned this Jul 17, 2024
@j-emberton
Copy link
Collaborator Author

Possible solution:

Create a python file with the following contents and add to sphinx project:

`# sphinx_initvar_filter.py
from sphinx.ext.autodoc import ClassDocumenter, ModuleLevelDocumenter
from sphinx.util.inspect import getdoc
from sphinx.util import logging

logger = logging.getLogger(name)

class InitVarFilterDocumenter(ClassDocumenter):
def add_directive_header(self, sig):
self.options.noindex = True
super().add_directive_header(sig)
self.options.noindex = False

def filter_members(self, members, want_all):
    filtered_members = []
    for name, obj in members:
        if not name.startswith('__') and 'InitVar' not in str(obj):
            filtered_members.append((name, obj))
        else:
            logger.info(f'Filtering out: {name} ({obj})')
    return filtered_members

def setup(app):
app.add_autodocumenter(InitVarFilterDocumenter)`

Then modify conf.py to include the custom operation:

`# conf.py
extensions = [
'sphinx.ext.autodoc',
'sphinx_autodoc_typehints',
'sphinx.ext.napoleon',
'sphinx_initvar_filter' # Add your custom extension here
]

autodoc_typehints = "description"
autodoc_typehints_format = "short"`

@j-emberton
Copy link
Collaborator Author

Hasn't been tried and tested yet

@MarionBWeinzierl MarionBWeinzierl moved this to Priorities and low hanging fruit in ICCS development board Jul 18, 2024
@j-emberton
Copy link
Collaborator Author

also more in pressure submodule:

Screenshot 2024-07-18 at 14 22 46

@davidorme
Copy link
Collaborator

I suspect this might be linked in to the state of our nitpick_ignore settings in the sphinx conf.py, which is a total dumpster fire of things that sphinx moans about.

nitpick_ignore = [
("py:class", "numpy._typing._array_like._ScalarType_co"),
("py:class", "numpy._typing._generic_alias.ScalarType"),
("py:class", "numpy.float32"),
("py:class", "numpy.timedelta64"),
("py:class", "numpy.bool_"),
("py:class", "numpy.ndarray"),
("py:class", "numpy.dtype"),
("py:class", "numpy.dtype[+ScalarType]"),
("py:class", "numpy.typing.NDArray"),
("py:class", "dataclasses.InitVar"),
(
"py:class",
"dataclasses.InitVar[numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]]]",
),
(
"py:class",
"dataclasses.InitVar[numpy.ndarray[typing.Any, numpy.dtype[+_ScalarType_co]]]",
),
(
"py:class",
(
"tuple[numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]], "
"numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]]]"
),
),
(
"py:obj",
(
"typing.Union[~numpy.ndarray[~typing.Any, "
"~numpy.dtype[~numpy._typing._generic_alias.ScalarType]], "
"tuple[numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]], "
"numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]], "
"numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]]]]"
),
),
(
"py:class",
(
"tuple[numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]], "
"numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]], "
"numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]]]"
),
),
(
"py:class",
(
"tuple[numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]], "
"numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]], "
"numpy.ndarray[typing.Any, numpy.dtype[+ScalarType]]]"
),
),
]

@davidorme
Copy link
Collaborator

@j-emberton
Copy link
Collaborator Author

Nice find.

is there a simple way to build the docs locally to test the changes?

@davidorme
Copy link
Collaborator

Should be able just to do cd docs; poetry run make html. All the requirements for docs are included in the poetry requirements. It doesn't seem to work though 😢

@j-emberton j-emberton linked a pull request Oct 7, 2024 that will close this issue
5 tasks
@j-emberton j-emberton linked a pull request Oct 7, 2024 that will close this issue
5 tasks
@MarionBWeinzierl
Copy link
Collaborator

Should be able just to do cd docs; poetry run make html. All the requirements for docs are included in the poetry requirements. It doesn't seem to work though 😢

It does work for me.

@MarionBWeinzierl MarionBWeinzierl self-assigned this Nov 26, 2024
@MarionBWeinzierl
Copy link
Collaborator

Hm, I tried adding

autodoc_typehints_format = 'short'
python_use_unqualified_type_names = True

to conf.py , running sphinx-apidoc, and a couple of other things suggested on stackoverflow&Co, but it seems to make no difference whatsoever. I am wondering whether I need to regenerate something further down?

@MarionBWeinzierl MarionBWeinzierl moved this from In Progress to Icebox in ICCS development board Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Icebox
Development

Successfully merging a pull request may close this issue.

3 participants