[Doc-SIG] "inverse" documentation generation
vlb at ironport.com
Thu May 12 19:56:33 CEST 2005
And now for something (perhaps) completely diifferent.
Most "documentation generators" are optimized for someone working
_on_ the code rather than _with_ the code. That is, they work from
the assumption that you have a method/class/module and want to know
how it works - not from the view that you know what you want to do
and want to discover the best method/class/module that will let you
accomplish your goal in the least amount of time and effort :)
I want to be able to generate documentation that aids a client in
using a set of Python modules, not in implementing and maintaining
Bob is using an automated test framework written in Python. He's
writing a test and he'd like to call a routine that will "be like
hitting return over and over until it gets me back out to the top of
my test." He asks John (one of the framework authors) who says:
"We've got that; it's called restart".
Bob then hunts through the pydoc documentation for the 100
modules and packages in the framework, then resorts to a find command
on the source tree (searching for for "def restart"), and eventually
discovers 5 different "restart" methods scattered throughout the
code. Back in pydooc, he sees that one of these has a docstring that
looks like "the right one".
Resets the session to a base state, ready for more method calls.
The rest appear to be internal methods, not API at all.
If John wasn't available, how would Bob ever discover this
method? He doesn't know its name. He doesn't know which class or
module it's in. He doesn't want to read through pages of pydoc HTML
files or familiarize himself with the entire framework code base. He
wants to _write a test_.
Even if he started with a"find" on the source tree (or a search
through the HTML-ized docs), he may not pick the right keywords for
I need a way to enhance Bob's efficiency as a client of the
framework, not a developer of the framework.
At the very least, I think what I want is a way to extract the
method, class, and module names, and their docstrings, and present
them in an inverse presentation format: instead of digging down
through module to class to method, I want to start from the
docstrings. I want to start from the viewpoint of "I know what I want
to do. Now tell me how to do it".
Comments, suggestions, ideas, and general discussion welcomed.
Vicki Brown <vlb at ironport.com> * Internal Technical Documentation
http://home.ironport.com/~vlbrown * Jabber: vlbrown at ironport.com
* Words are, of course, the most powerful drug used by mankind. *
-- Rudyard Kipling
More information about the Doc-SIG