How docvet learned to read Sphinx and NumPy docstrings

The problem: one inspector, one language docvet checks whether your Python docstrings are present, complete, accurate, and renderable. Since v1.0, it's caught missing Raises: sections, stale docstrings after code changes, broken mkdocs rendering, and more — 22 rules across five check modules. But it only understood Google-style. That's a problem, because a huge portion of the Python ecosystem uses something else: Sphinx/RST style ( :param name: , :returns: , :raises: ) — Django, Flask, SQLAlchemy, requests, boto3, CPython stdlib NumPy style (underlined section headers) — NumPy, SciPy, pandas, scikit-learn, matplotlib If you maintain a Django app or a scientific Python library, docvet's enrichment checks couldn't parse your docstrings. As of v1.13.0, that's fixed. How style support works It's a project-level setting, not auto-detection docvet doesn't guess your style per-file. You tell it once in pyproject.toml : [tool.docvet] docstring-style = "sphinx" Two valid options: "google" (defa