[Epydoc-devel] [Fwd: Some ideas for epydoc]

[Reinhard M. <rei...@by...>]

Hello,

I sent the mail quoted below to edloper at gradient dot cis dot upenn
dot edu more than a month ago, but I didn't receive any reaction so far.

Is the epydoc project still alive at all? Is this list the right place
to ask such questions?

Thanks,
Reinhard

-------- Weitergeleitete Nachricht --------
Betreff: Some ideas for epydoc
Datum: Wed, 01 Jun 2005 14:43:38 +0200
Hi,

we excessively use epydoc in the GNU Enterprise project
(http://www.gnuenterprise.org).

When I was playing with epydoc, I stumbled across a few points which I
could be an improvement for epydoc:

* If epydoc is run on a certain source tree, it even imports and
processes modules outside the source tree if they are used (imported)
within the code. It might be a good idea to provide an option to turn
this off. Example: if any of my code contains the line "import
SocektServer" (a standard Python module), epydoc parses the docstrings
of SocketServer.py (provided by Python) which unfortunately isn't valid
epydoc syntax, so an error message is generated.

* We sometimes import modules that add an identifier to __builtins__.
Whenever such an identifier is used in module initialization code,
epydoc stumbles over that.

* When a module generates a exception when imported, it would help if
there was a way to get the *full* traceback instead of only the
exception text.

* I would love an option to make epydoc output sorted in the order of
appearance in the file instead of alphabetically. This way, a logical
order of e.g. functions within a class in the source code would also end
up in a logical order of the function descriptions in epydoc output.

As epydoc has helped us a lot in the past, I would be willing (and able)
to donate some manpower to epydoc (I represent a company). So I would
appreciate your feedback on whether you would accept and incorporate
patches to epydoc that solve the above points.

Thanks,
Reinhard