Add option to include docstrings with stubgen by chylek · Pull Request #13284 · python/mypy

added 5 commits

July 29, 2022 10:12
Add a --include-docstrings flag to stubgen
This was suggested in python#11965.
When using this flag, the .pyi files will include
docstrings for Python classes and functions and
for C extension functions.

@chylek chylek marked this pull request as draft

July 29, 2022 10:07

@chylek chylek marked this pull request as ready for review

July 29, 2022 10:52

@chylek

@chylek

sobolevn

@chylek

@chylek

@chylek

@chylek

@chylek

@chylek

@chylek

@chylek

@chylek

@chylek

ilevkivskyi

@hauntsaninja

@chylek

ilevkivskyi

yosh-matsuda added a commit to yosh-matsuda/mypy-nanobind that referenced this pull request

Oct 13, 2023

This was referenced

Nov 15, 2023

JelleZijlstra pushed a commit that referenced this pull request

Nov 29, 2023
This addresses several regressions identified in
#16486

The primary regression from #15770 is
that pybind11 properties with docstrings were erroneously assigned
`typeshed. Incomplete`.

The reason for the regression is that as of the introduction of the
`--include-docstring` feature
(#13284, not my PR, ftr),
`./misc/test-stubgenc.sh` began always reporting success. That has been
fixed.

It was also pointed out that `--include-docstring` does not work for
C-extensions. This was not actually a regression as it turns out this
feature was never implemented for C-extensions (though the tests
suggested it had been), but luckily my efforts to unify the pure-python
and C-extension code-paths made fixing this super easy (barely an
inconvenience)! So that is working now.

I added back the extended list of `typing` objects that generate
implicit imports for the inspection-based stub generator. I originally
removed these because I encountered an issue generating stubs for
`PySide2` (and another internal library) where there was an object with
the same name as one of the `typing` objects and the auto-import created
broken stubs. I felt somewhat justified in this decision as there was a
straightforward solution -- e.g. use `list` or `typing.List` instead of
`List`. That said, I recognize that the problem that I encountered is
more niche than the general desire to add import statements for typing
objects, so I've changed the behavior back for now, with the intention
to eventually add a flag to control this behavior.