-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
More robust docstring support #1840
Comments
Pretty sure this has been discussed numerous times: |
The thing that confuses me is that docstring parsing is already in mypy, it's just not very good. I assumed that if the team was ideologically opposed to this that the feature would simply be absent. Should we close this issue or is there some hope? |
Hmmm... I see that the feature is disabled. Or more accurately that the result of parsing docstrings is always ignored. |
It looks like it was a Dropbox "hack week" project, which means it was an experiment. I am still philosophically opposed to it (just read the other issues, I don't want to have to repeat myself). |
I think that there will continue to be a demand for this feature because of the reasons I listed above, but I understand that you don't want to support this in mypy. So I'd like to propose a compromise solution: an optional, user-supplied callback function for processing docstrings. Something like this:
This will enable those who need this feature to get it using third-party tools, which you will not have to write or support. The callback would be called in place of If the docstring-specific nature of this request is unappealing, an alternative would be to allow the passing of a custom
Would either of these solutions be acceptable? |
I wonder if this could fall under the plugin design. There's an issue but
I've forgotten the number.
…--Guido (mobile)
|
It's #1240. |
Core mypy just won't support this, and I'm closing this as wontfix to reflect that. You are welcome to write a script that converts docstrings to PEP 484. Once we have a plugin system you are also welcome to write a plugin for this. |
Hi,
I was perusing the mypy repo and I discovered that mypy can parse docstrings. That's great! The support, however, is currently pretty basic. For starters, mypy currently only supports the google standard. From looking at the code, my instincts tell me that it might be somewhat fragile when exposed to a lot of real-world docstrings.
First, my motivation for using docstrings to provide typing information is the following:
At this point, the python community semes to have settled on three docstring standards:
Sphinx supports the first out-of-the-box, with the latter two supported via the very nifty napolean extension, which comes bundled in sphinx-contrib. It works by converting google and numpy docstrings into reStructuredText, which is then parsed using docutils. Napolean is quite thorough, very battle-tested, and just forgiving enough on docstring authors to be usable (supports
Return
as well asReturns
,Yield
as well asYields
). Here's the relevant code. Also, handily enough, napolean already supports PEP848-style type hints. It depends onsix
and pockets but the latter could easily be removed.My thought was that we could leverage napolean and docutils to get rock-solid parsing of all 3 formats. I'm assuming that adding dependencies to mypy is best avoided, so perhaps it can be installed as an
extras_require
. e.g.pip install mypy[docparse]
. To avoid requiring all of sphinx, we could encourage the authors of napolean to provide the guts of their tool as a separate library (it used to be its own repo before it was consumed by sphinx-contrib).What do you think? I'm glad to do all the work, including talking with the author of napolean, but I wanted to first see if this is something that the mypy team is open to.
Thanks!
The text was updated successfully, but these errors were encountered: