-
-
Notifications
You must be signed in to change notification settings - Fork 74
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
Improved param and rx docs #977
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #977 +/- ##
=======================================
Coverage 87.35% 87.36%
=======================================
Files 9 9
Lines 4935 4938 +3
=======================================
+ Hits 4311 4314 +3
Misses 624 624 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
As I am not a regular contributor to param it would help me to get a review, feedback and merge of this "smaller" PR. Then I would feel confident making a larger PR more systematically going through |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much! Love it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's see if @philippjfr has anything to say.
Co-authored-by: Simon Høxbro Hansen <simon.hansen@me.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found inconsistencies in the formatting of the docstrings added in this PR. I also wonder if the links shouldn't point to the reference API instead of to the user guides.
Before merging, I'd recommend building the dev site from this branch and checking that the generated API ref is correctly formatted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is well overdue, so thanks for doing it. Let's make sure that we consistently use NumPy style docstrings though, right now this is an odd mix.
If think I should investigate whether ruff or something else can validate this. I'm not using Numpy Docstrings very much. So I will fail at this. |
Thanks so much for the feedback. Will correct it ASAP. |
…into enhancement/rx-docs
Co-authored-by: Maxime Liquet <35924738+maximlt@users.noreply.github.com>
I've updated the docstrings. Also means the code blocks are now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates Marc!
I see that Panel also has its examples code doctest formatted (>>> <code>
). What's your experience using this format? I know that it sometimes annoys me as copy/pasting it (from a website, a docstring tooltip in an IDE, etc.) doesn't always strip >>>
so you have to manually remove them. IIRC the ipython
interpreter strips them out but not the base python REPL. The advantage of this format is that it enables running doctest which might be a good idea. By the way, I have no strong opinion over all of that, just trying to gauge the user experience.
I also think they are hard to copy. But I changed them because of request to use numpy docstrings. I believe that is the format. |
I believe I got the feedback from @maximlt above that So even though Alternative would be markdown code blocks. But numpy docstyle is rst. |
Could you show what that format looks like in the code? I'd also like to know how it will end up being displayed:
|
I'm simply not prepared to do that work again. I tried to analyze situation when started doing this for Panel. And the learning is there is no way that works great. If you are happy with Panel I'll do it like that. That is what I can offer. Panel seems to be using |
Ok sure I understand, this is all a bit of a mess.
Could you show how you plan to change it with an example? For example, how will this docstring look like with the change you plan to make?
Then I can look a little bit what would the user experience be on various platforms (VSCode, JLab, website, etc.). Just linking something that I wasn't aware of, the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks very useful; thanks @MarcSkovMadsen !
Co-authored-by: Maxime Liquet <35924738+maximlt@users.noreply.github.com>
Co-authored-by: Maxime Liquet <35924738+maximlt@users.noreply.github.com>
…into enhancement/rx-docs
The below is how it looks in my version of VS Code on windows with pylance. I don't have the latest version of VS Code. For me that is fine. It looks good. The vs-code.mp4VS Code and jedi-language-server actually works better because it strips out the vscode-jedi-language-server.mp4 |
Attempt to make
.param
,.rx
and.rx()
easier to use by improving docstrings.Currently I meet a lot of dead ends because of missing or very sparse docstrings.
For example
.rx
in example below has no docstring which makes it almost impossible to use without already knowing how.Its the same for
.param
. There is no docstring.I do believe it would help users tremendously if there where docstring and improved docstrings. It would make the
.param
and.rx
namespaces so much more inviting and easy to use.Guiding Principles