-
-
Notifications
You must be signed in to change notification settings - Fork 110
Use Sphinx autodoc for documentation. #443
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
Conversation
Existing API docs were moved into docstrings, and Sphinx's autodoc extension is used to generate the API reference automatically.
Without this, autodoc was adding the close method to all the subclasses of MSSBase that implemented it. It didn't add things like grab and such, since the subclasses didn't implement it. While I'm at it, also make the close method safe to call multiple times.
|
I suspect that the errors are about the changes to how close() is handled, but I'll investigate. I can reproduce them here with xvfb-run. |
|
Nice!
No, that's OK to document only objects that users will encounter. |
First, we previously patched ctypes.WINFUNCTYPE in any time mss.windows was imported, so that autodoc could import mss.windows. Instead, move that to just when we're running Sphinx. Second, when I added _close_impl, I accidentally deleted the super() call in xshmgetimage. This mean that it never closes connections, and exhausts the server's client limit. Finally, in a previous commit, I tested changing mss.lock from a Lock to an RLock while I was dealing with the fact that MSSBase.close holds the lock, and the xlib implementation grabs the global lock. That was not a great solution, so I backed that out. Instead, the xlib implementation just trusts that it's run under the lock. However, a better implementation might be to create a per-object lock in MSSBase to protect _closing, instead of using the course-grained global lock.
This adds extra detail to some docstrings, and brings formatting in line with Sphinx conventions.
|
Should we merge this, and iterate if needed? |
Yeah, that's what I planned last night... then came across that last batch of doc fixes I added to the PR! Later today, I can incorporate your suggestions, check the doc build, and mark the PR as ready. |
Most constructor parameters weren't being documented by autodoc, since __init__ wasn't documented. If we added the __init__ docstrings to the class documentation (autoclass_source="both"), then that puts an awkward "Initialize a ScreenShot object" or similar sentence in the class constructor documentation in the rendered output. Instead, we put the __init__ parameter docs in the class docstring, and removed __init__ docstrings. Added "See also" sections to make looking up constructor parameters across __init__(**kwargs) chains a little more obvious. Added other requested changes: * Added mss.darwin.IMAGE_OPTIONS to the docs * Added docstring for mss.darwin.MSS.max_displays instance variable * Added docstrings to NamedTuple classes in mss.models * Added formatting for code samples in ScreenShot.bgra and rgb
|
Thank you very much @jholveck, that's cleaner now, and properly documented from the code. I love it! |
This changes the API documentation generation to use Sphinx autodoc. The existing API docs were moved into docstrings.
There's still cleanups to be done on the documentation, but this seemed like a place to start.
My change does delete some imported classes and constants that were in the API docs for reasons I'm not really clear on, such as mss.darwin.CGPoint and mss.windows.MONITORNUMPROC. Should these still be in the docs?