10 comments

[ 4.5 ms ] story [ 32.7 ms ] thread
I'm a big fan of pdoc and have used it in a couple projects.

It makes really nice use of python docstrings and is overall just really easy to use!

Had to recently document a Python library / API; it was not for public consumption. I took inspiration from pyserial [1] and made sparse docstrings which in turn reduced potential clutter making things easier to read and digest; and provide a more elaborate (hand generated) documentation in the sphinx documentation rendered as html/pdf. I quite liked this balance. The obvious trade off is the sphinx documentation may go out of sync with what is in the code, but eh if it happens it won't be the end of the world and is quickly rectified.

[1]: https://pythonhosted.org/pyserial/

Hey I’m in the process of documenting a library for my startup, do you have any more thoughts about your process?
Pdoc is great. I tried mkdoc and others, but pdoc was so much easier. One command and you're done. Trivial to add to a Github workflow & Github pages.
Pdoc is great. I love it.

But there is one blemish.

They write on documenting variable assignments which don't support pythons __doc__ string:

> To compensate, pdoc will read the abstract syntax tree (an abstract representation of the source code) and include all assignment statements immediately followed by a docstring

I can't really understand that. I am programming Python for 14 years now, and any real codebase I have ever seen documents variables above their declaration. Even if there is some technical reason for it, if I saw a python developer comment what a variable declaration means below that declaration I would at least question their taste.

To me that particular implementation is so bad, that I would prefer pdoc without it.

pdoc maintainer here. Pleasant surprise to see us on HN again, and happy to answer any questions! :)