-
Notifications
You must be signed in to change notification settings - Fork 487
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
Display multiline docstrings #841
Comments
@gsganden many thanks for the thoughtfully-presented and well-researched issue. Frankly, this decision goes back (IIRC) to the earliest days of nbdoc, the module that proceeded nbdev. At that stage, this whole approach was an early research idea and I was wondering how best to bring code into notebooks. Pretty much none of the code I was working with was designed to render nicely in notebooks, so I figured just keeping the first line of the docstring seemed like a reasonable compromise -- and then add prose in the notebook to explain any extra details. Nowadays we have stuff like docments and numpy docstring rendering -- things are pretty different. I don't think that our original design decision makes sense. So I've changed it in master to show the whole docstring. If it turns out that it's not ideal in some situations, we could always add a param to showdoc to make it optional. To render it better in HTML we'd need to replace 2+ CRs with |
I have a class with a docstring that looks like this:
I would like to display that docstring on my documentation site as it appears there, but neither of the provided renderers does the job. The default
BasicMarkdownRenderer
takes only the first line, so it removes the note about usingget_inspector
:BasicHtmlRenderer
shows the note, but without the line breaks separating the text blocks (and without the docment table):I understand that I can plug in my own renderer, and I suspect that at least some of this behavior is the result of deliberate choices. I am wondering if you would want to either (1) change any of the behavior of the provided renderers or (2) provide additional renderers in the library. For instance, it might be helpful to provide renderers that display traditional NumPy- or Google-style docstrings in full for the sake of showing third-party library docs even if you want to encourage more succinct docs by default. I'd be happy to submit a PR if we can align on requirements.
The text was updated successfully, but these errors were encountered: