There seems to be a plethora of documentation tools for Python. Another one that I've run across is epydoc. It seems like Sphinx is the de facto standard, because it's used to generate the official Python docs. Can someone please sort out the current state of Python's documentation tools for me?
-
Current State? What does that mean? Can you expand on that? Sphinx requires docutils; epydoc can use the same RST notation. What do you want to know? Can you be more specific? – S.Lott Mar 14 '10 at 03:40
-
eg what tools have strong community support, active development? Is there an incumbent solution, or are there many with none having significantly larger following? – allyourcode Mar 15 '10 at 06:18
-
1Maybe you should edit the title of this question. – Étienne Aug 27 '14 at 16:13
3 Answers
epydoc and Sphinx are different types of tools.
They are the same in that they:
- Both use ReST via docutils.
- Both are very Pythonic in their focus
- Both can generate HTML and PDF documentation
They are different in their focus.
- Epydoc is focused on API (Developer) documentation. You get more results quicker with Epydoc. You point it at your source code and you get something. This is what I want from an API documentation tool.
- Sphinx is focused on general (User) documentation. While Sphinx does pull a lot of information from your source code you need to put a little more into it. Sphinx can generate API documentation but, it's not as straight forward, and IMO doesn't do as good of a job as Epydoc. I know some will disagree because Sphinx is chosen for Python. BUT, it depends on how much work you want to put into it. I do love Sphinx for general documentation.
So it depends on how much work you want to put into it and what you are documenting.

- 1,354
- 1
- 15
- 25

- 2,724
- 28
- 26
-
1Thanks for explaining what these tools have in common (eg their relationship to docutils) as well as their differences. What makes epydoc better for API documentation and Sphinx better for functional documentation? You mentioned that they both use reST. Seems like there's alot of overlap. Is it just a matter of convenience? Also, epydoc development doesn't seem to be very active. The last commit was in Feb 2009, and the last correspondence on the devel list was in May 2009. – allyourcode Mar 15 '10 at 06:14
-
2Well, the easy answer to why one is better at one thing that another is that is the way they were designed. Epydoc is made to just pull from the code and Sphinx is made to generate a lot of it's documentation from ReST files you write. There is a lot of overlap. Sphinx is the new kid on the block. I've heard rumors that in .7 it will have much better auto-generation built in. I have a lot of respect for Epydoc but Sphinx seems to have all the momentum right now. I like it because it looks like the python.org documentation AND I think it looks better. – Paul Hildebrandt Mar 15 '10 at 07:00
-
3Sphinx is not focused on general User documentation. Sphinx is a tool which helps you write a complete and detailed documentation, which you simply cannot provide by concatenating docstrings. Also Sphinx will support so-called domains with 1.0 which will allow you to document a project written in multiple languages for example a webapp written in Python, Javascript and C. – DasIch Mar 15 '10 at 23:08
-
1I was about to ask for pointer on how Sphinx generates API docs and then I found [this](http://www.gossamer-threads.com/lists/python/dev/726475) post of yours. `sphinx.ext.autodoc` *doh*. Thanks. – muhuk Apr 22 '10 at 11:19
I recently changed from Python2 to Python3 and found that there was no Epydoc package for Python3. So it seems with Python3 there is a clear focus on using Sphinx as API documentation.

- 5,321
- 6
- 33
- 51
It seems like Epydoc is, if not dead, at least pining for the fjords.
Sphynx with the sphinx-apidoc command and the autodoc extension looks to be the most popular option for API docs at this time.
Good examples are:
See: Should we use Epydoc, Sphinx or something else for documenting Python APIs? (SO5579198)
Sphinx encourages a more narrative style than tools in the javadoc mold, but maybe this is a good thing?