That’s really not the case, we have real-world examples from use in FastAPI as a test bed that were brought up earlier in the thread.
And the fast API example also involves referencing other docs by URL, so if we were to hold what some people said is a goal of not doing that, it would be even worse.
Sorry that this was unclear. The old Google Style would be worst cast scenario +1 LOC per parameter vs this new style because old style requires the parameter name (and maybe type) to be repeated on two lines.
I think that the FastAPI init is quite an extraordinary case in which there are many parameters and each one has multiline documentation, going so far as to include example usage. Because this forces the type to be on its own line, and because the docstrings begin on a newline for clarity, I will concede that the FastAPI init would be fewer LOC in a traditional style vs the new style. Nevertheless, I find the doc style of that init signature to improve the readability of the function signature, source code, and documentation overall because the documentation is tightly coupled with the parameter.
There is no standard way of making see:func: xyz jump to docs being referenced, no?
I want to put the docs for frequently used variables in a central place, explicitly not disrupting the flow of the code, but leveraging the IDE to just look at the variable if I want to, just like with any other variable definition. I don’t want to compile and jump back and forth between the IDE and the docs, that is a really bad dev experience IMO.
see :func:`xyz` is Sphinx syntax. It won’t do anything clever for just calling help(some_function) in a REPL. I think PyCharm might try to render Sphinx docstrings (it’s a while since I used it) and therefore possibly cross references. The general answer though is no, it’s a genuine caveat that most of the ways you can look at a docstring are just plain text.
On the flip side though, mouse hovering over a function and a function help display dialog so large that it doesn’t fit on the screen popping up isn’t particularity great either.
If the alternative of standardizing the big 3 docstring formats happened instead of this, it’s possible that more IDEs would be willing to add support for following/viewing references in these standard formats, but for sphinx at least, this would mean that IDEs would either only support fully qualified references from the project + the standard library and builtins, guess when it comes to intersphinx, or need to be able to understand and look for intersphinx (not that this is difficult, but that it’s a consideration)
There are certainly other less disruptive ways here that we can look to for improving people’s ability to navigate documentation without needing to open a fully rendered docs site.
I was just made aware of “docments”: Docments – fastcore.
Without docments, if you want to document your parameters, you have to repeat param names in docstrings, since they’re already in the function signature. The parameters have to be kept synchronized in the two places as you change your code. Readers of your code have to look back and forth between two places to understand what’s happening. So it’s more work for you, and for your users.
Furthermore, to have parameter documentation formatted nicely without docments, you have to use special magic docstring formatting, often with odd quirks, which is a pain to create and maintain, and awkward to read in code.
That rings a bell 
God help us if writing a parameter name more than once becomes a crime…
def do_nothing(x):
return x # Ahh! I wrote 'x' twice! The duplicity, it burns!