On Jan 23, 2006, at 4:20 PM, Jeff Watkins wrote:


On 23 Jan, 2006, at 6:06 pm, Bob Ippolito wrote:
Hacking docutils isn't all that hard.

I would like to suggest that we choose something that doesn't require hacking. If it doesn't work easily, it won't get used. Documentation and tests (I'm guilty on this) is usually the last thing to get done because the fancy tools need hand-holding.

Let's pick something that *already* works and run with it.

Nothing already works. I've been doing Python for a few years now, and all the mature docs-from-source tools suck hard. The signal:noise ratio is like 0.001, and/or the docstring markup is stupid. I do not want my source code to be <b>@ugly</b>. It's WAY more efficient for me to grep the source and read the docs in source form than to navigate a 2000 file three-frame HTML document tree.

Docutils comes very close to being good as an external document tool, but it needs a couple lines of domain-specific roles in order to make cross-referencing work well. That's a pretty big barrier to entry, but the markup is excellent and the output is flexible. For MochiKit, it was more than worth writing forty lines of code or so to make that happen (most of the code revolves around just finding the doc files, not the roles).

What's needed in this case is a doc-from-source tool, which pretty much leaves just Pudge and PythonDoc as decent options. Pudge has docutils behind it, but is nascent. PythonDoc is a bit more mature, but it requires inline HTML for any markup that isn't represented by the PythonDoc @tags (e.g. emphasis, tables, etc.).

For an example of what docutils markup looks like in source code, you could take a look at some of simplejson's source:
http://svn.red-bean.com/bob/simplejson/trunk/simplejson/encoder.py

and the Pudge output:
http://svn.red-bean.com/bob/simplejson/trunk/docs/class- simplejson.JSONEncoder.html http://svn.red-bean.com/bob/simplejson/trunk/docs/simplejson/ encoder.py.html?f=63&l=277#63

For me, it was well worth a little hacking to make sure my (a) source wasn't fugly (b) the output is navigable.

Compare this index page to TurboGears, for example:
http://svn.red-bean.com/bob/simplejson/trunk/docs/index.html

In this case, Pudge puts all the information you need in one place, **skipping over irrelevant modules, like the tests**, instead of just a long unfiltered list of modules with mostly meaningless comments (when there are comments). API documentation should absolutely not include tests or private APIs that the user doesn't need to know about. That's what the source is for.

I had to make some slight changes to Pudge in order to make that happen, but nothing big, and I didn't spend very long on it. I'm not saying Pudge is painless, because it's not, but at least the output is useful.

-bob

Reply via email to