-
Notifications
You must be signed in to change notification settings - Fork 291
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
Add Sphinx docs customization for multimethod #1088
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1088 +/- ##
=======================================
Coverage 96.34% 96.34%
=======================================
Files 40 40
Lines 9533 9533
Branches 1259 1259
=======================================
Hits 9185 9185
Misses 205 205
Partials 143 143
📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
Handle multimethod class methods in automodule customization Update sphinx pin Update .gitignore for vim
@lorenzncode I think this looks good. Is it ready for review? |
Yes, this is ready for review. Thanks for taking a look. |
@Peque You have done a lot with our Sphinx setup before, do you have the time and interest to take a look at this PR? @lorenzncode I get the following warning when I generate the docs, are you getting it as well? |
@jmwright Not the time, but thanks for the ping! 😊 |
Thanks @jmwright. Yes I reproduced the warning. I've pushed a change to address the warning by setting the |
Thanks @lorenzncode Other than the two other comments I think this PR looks good. I'm not sure who else will review it. @adam-urbanczyk are you available to do it? |
@jmwright i can review, I probably can get to it early next week |
@dcowden Great thanks! |
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.
+1 |
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.
Definitely not a sphinx expert here, but looks ok to me
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.
@lorenzncode Thanks! Feel free to merge if you think it's ready. You might want to start a new issue for the comment made by @adam-urbanczyk . I think this is a nice stand-alone PR as-is, but that's a possible future change.
# of inner classes can be documented | ||
full_name = modname + "::" + full_name[len(modname) + 1 :] | ||
# NB. using full_name here is important, since Documenters | ||
# handle module prefixes slightly differently |
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.
Are the extra preceding spaces in this comment intentional?
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 extension creates a subclass of sphinx.ext.autodoc.MethodDocumenter
overriding method format_signature
and a sublcass of sphinx.ext.autosummary.AutoSummary
overriding get_items
. Actually this comment comes from the original implementation of get_items
. I didn't change the formatting other than run black. I would suggest to keep the extra spaces as is to help diff in the future say when checking for compatibility with a new Sphinx release (I'll add a note on maintenance).
@@ -782,7 +782,7 @@ def arc( | |||
forConstruction: bool = False, | |||
) -> T: | |||
""" | |||
Construct an arc starting at p1, through p2, ending at p3 |
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 was actually added in a fairly recent PR. https://github.com/CadQuery/cadquery/pull/1049/files
What's the reason for removing 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.
Right, this was intentionally reverted back to the original docstring. The original docstring has a generic description that is applicable to all of the dispatch methods which is better than a description specific to only one of the methods.
I agree the vertical field list for each prototype would be nice to try. Unfortunately it does not look easy to me. This PR attempts to bring multimethod support more in line with how Sphinx handles |
Notes on maintenance: When updating to a newer Sphinx version, test that the extension is working. The extension depends on Sphinx autodoc and autosummary and may require updates depending on changes to Sphinx (there were none from v4.5 to v5.0 so far). Compare |
I pushed a minor change to a .gitignore entry added in this PR. If there are no other issues, this is ready to squash and merge. |
Thanks @lorenzncode I re-ran the randomly falling test on Windows and it passed the second time. |
No worries, thanks for the hard work! |
This adds customization to better handle multimethod in the HTML docs. To resolve #1087.
Now multimethod is handled in a similar way as
overload
andsingledispatch
.