Thansk for the feedback @mikeshardmind (also pre-discuss).
The problem with another Python syntax being supported would be that it would be quite invasive, it would “reserve” that syntax exclusively for this purpose, it could require implementation changes for Python or the types themselves (e.g. supporting
__matmul__ in types), and that would make it non-backwards compatible.
The idea with this proposal is that it would be as little invasive as possible, and as optional/opt-in as possible as well.
Parsing docstring formats is non-trivial (more about it in a previous reply by @pawamoy). If in your libraries and use-cases you can afford to be tightly-coupled to sphinx, have it as a dependency and use it to extract the info, etc. that’s perfectly fine, and I would definitely not expect people in that position to adopt this, the problem is that it doesn’t apply to everyone else. For example, in FastAPI I can’t depend on Sphinx to extract parameter documentation (the same with Pydantic, Typer, etc).
I wouldn’t expect people that are already comfortable with their workflows to change or migrate. I consider it purely opt-in, as are for example
TypeDicts, not everyone bothers to use them, but it’s there in the standard for those that want to use them.
Additionally, although yes, this is another way to spell the same thing, this would be the first one to be somewhat standardized, all the other docstring formats are microsyntax conventions for each specific tool that also require quite some learning. This would hopefully be fairly easy to learn, for those that want to adopt it, as it’s the same Python syntax.
Edit: I just realized I can reply/quote multiple things in a single post, so I’ll reply to the other things here.
Yep, if you consider the docstring independent of the parameters, then the verbosity of the parameters would increase, at least for those using this.
This would be beneficial mainly for people writing and maintaining docstrings that have to scroll back and forth when dealing with and documenting a specific parameter.
At the same time, if this feels more cumbersome to use than to maintain the docstring independently, even with the info duplication, etc. I wouldn’t expect it to be used in those teams and projects.
I particularly don’t expect existing codebases and projects that are comfortable with their setup to migrate to this.
But I would expect new tools and projects to find this a bit simpler to use than to learn and acquire the expertise and workflows needed to use previous tools based on different microsyntax formats.