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

More robust docstring support #1840

Closed
chadrik opened this issue Jul 9, 2016 · 8 comments
Closed

More robust docstring support #1840

chadrik opened this issue Jul 9, 2016 · 8 comments

Comments

@chadrik
Copy link
Contributor

chadrik commented Jul 9, 2016

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:

  1. Our company is already doing it throughout our codebase
  2. It's nice to include type info alongside the description of an argument, so even with PEP484 now in python 3.5, I'll continue to enforce the use of proper docstrings
  3. It works in both python 2 and 3

At this point, the python community semes to have settled on three docstring standards:

  • reStructuredText
  • google
  • numpy

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 as Returns, Yield as well as Yields). Here's the relevant code. Also, handily enough, napolean already supports PEP848-style type hints. It depends on six 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!

@refi64
Copy link
Contributor

refi64 commented Jul 9, 2016

@chadrik
Copy link
Contributor Author

chadrik commented Jul 9, 2016

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?

@chadrik
Copy link
Contributor Author

chadrik commented Jul 9, 2016

Hmmm... I see that the feature is disabled. Or more accurately that the result of parsing docstrings is always ignored.

@gvanrossum
Copy link
Member

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).

@chadrik
Copy link
Contributor Author

chadrik commented Jul 10, 2016

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:

mypy --docstring-parser=mymodule.parse_docstring

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 mypy.docstring.parse_docstring and would also allow the complete removal of the mypy.docstring module.

If the docstring-specific nature of this request is unappealing, an alternative would be to allow the passing of a custom Parser class via the command-line.

mypy --parser=mymodule.MyParser

Would either of these solutions be acceptable?

@gvanrossum
Copy link
Member

gvanrossum commented Jul 10, 2016 via email

@gvanrossum
Copy link
Member

It's #1240.

@gvanrossum
Copy link
Member

gvanrossum commented Jul 14, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants