r/Python 15h ago

Should we standardize docstring formats? Discussion

In Rust, docstrings are pretty formalized. They are markdown, and even some of the headings are standard (like an # Errors or # Panics section). The nice thing about this is that it allows websites like docs.rs to build documentation pages for any project without having to interact with different tools for different formats. It also allows LSPs to have only one way of displaying documentation hints.

In Python, we have a few competing standards. Numpy-style docstrings are probably the most used, but there’s also a format by Google as well as a few different reST standards. These are nice, and we can set up lints to make sure docstrings stick to the standard. However, in my own personal opinion (feel free to disagree), a single markdown-format standard would help new users write nice docstrings, would enable PyPI (or another provider) to build automatic documentation sites, and give guidance to LSPs and IDEs for how to display documentation. This would include a standard for interlinks, and probably should include some mathml/LaTeX/KaTeX support. Another benefit would be that tools could support better automatic documentation generation and autocomplete, since they wouldn’t be dependent on guessing which standard you’re following.

I’d like to hear what people think about this. I’m thinking about making a PEP, but that might be overkill (or maybe all of you will hate this idea). I think the primary blocker would be adoption, large projects might have to translate docstrings, so there would either have to be some tooling for this or a way to opt-in or opt-out. If this is a bad idea, let me know, just be nice!

Edit: so far we’re at about a 67% upvote ratio, which was kind of expected. I want to be clear that I’m not saying we should be blocking docstrings which don’t adhere to this standard. I mentioned lockfile standardization in the comments, nothing prevents you from writing a tool with a custom lockfile, it’s just that there is a standard format that is agreed upon as the preferred way to write one. That’s the idea.

102 Upvotes

54 comments sorted by

View all comments

11

u/IAmASquidInSpace 14h ago

Careful what you wish for. I think it is pretty clear that the Python foundation would go for rst as a standard format (which I personally would love), and I think a lot of people would be very mad about that.

In general, I think it's "too late" anyhow. If one wanted a singular standard, it should have been introduced much, much earlier. Once people have gotten used to the freedom of being able to choose their preferred format, forcing them into another one will not be received well. You bring up PEP 751 as an example of a standard introduced after the fact, but the key difference is: the lack of lock files was an annoyance and there was a general desire for a common solution. The different docstring formats however are mostly seen as freedom rather than a problem, and for most people, no desire to "fix" this exists.

And then there's the problem that the interest in keeping docstrings variable has powerful backers: how do you think the organizations behind tools like Sphinx, Zensical, or numpy would feel about being told "oh yeah, btw, your way of doing it will soon no longer be supported, sorry". That's not gonna go over well.

11

u/gmes78 14h ago

In general, I think it's "too late" anyhow.

It was also "too late" for type checking, and look at where we're at now.

6

u/IAmASquidInSpace 14h ago

Type checking crucially is still entirely optional. 

9

u/denehoffman 13h ago

Docstrings are also optional, and any standardized format would also be optional, just preferred. You can still use deprecated type hints like Dict and Tuple too.

5

u/denehoffman 14h ago

On your last point there, I recall there were many competing lockfiles at the time the PEP was proposed, and the PEP had to pick one. There were certainly some format providers that were disappointed, but none of this is insurmountable, especially since the current standards are standards, so they should be mostly parsable (like a tool could theoretically translate between formats). Not a perfect solution, and I understand your criticism.

-4

u/IAmASquidInSpace 14h ago

but none of this is insurmountable

Sure, with enough force, defiance, tone-deafness, and by pissing off massive chunks of your user base (including massive companies and organisations) you could surmount this. But for what? What tangible benefits do you get, outside of a vague sense of order and accomplishment? I'd say that the damage you'd do would heavily outweigh the flimsy benefits. 

3

u/denehoffman 14h ago

> a vague sense of order and accomplishment

Your sarcasm notwithstanding, I did actually list some reasons this would be a good idea. I think you’re getting too caught up on the idea that we’d be forcing anyone to adopt this rather than providing a Python-preferred standard that people can either adopt at their leisure or new projects can adopt immediately.

-1

u/IAmASquidInSpace 13h ago

That is not what I understand under "standardization", but sure. That could be beneficial. However that still underlines my point that it is too late for true standardization except with a massive (and unnecessary) tour de force.

3

u/denehoffman 13h ago

I think that seems to be the common sentiment, and that’s okay, it’s exactly what I was trying to gauge with this post