Hi Terry, Terry Hancock writes:
... You've already got a patch to make pydoc recognize Python Methods This Python Method is not Zope's "Python Method" but that of "ExtensionClass".
"ExtensionClass" wraps what Python calls a "method" as a "Python Method", in order to do special things with it. Thus, almost all methods you see in Zope are "Python Method"s.
, but I noticed that DTMLFile() and SQL() objects show up as python methods when I examine their type. I do not understand that directly.
Seems, they somehow get identified with their "__call__" or "__init__" method. However, this seems strange.
So far the best way I've found to identify them is to look at their docstrings, which are inherited from the original DTMLFile/HTMLFile class and the SQL class respectively. It seems to me that it is a useful thing to be able to recognize whether a method is Python, DTML, ZSQL, ZPT, or whatever -- especially since they are usually used for different things. If they are Zope objects (they often are not, as explained above!), then you can use "meta_type" to distinguish between the various objects.
.... Also it seems like pydoc might be best invoked from within Zope, though I've been trying to do it from the interpreter with, e.g.:
import Zope Actually this generates a traceback, because the ZODB is supposed to be locked by my running Zope instance, but it seems to work anyway for my purposes. My "Pydoc support" package contains a patch to Zope that lets it correctly start in read only mode.
<http://www.dieter.handshake.de/pyprojects/zope>
... Unfortunately, I haven't figured out how to generate a full documentation set for the product this way -- I've managed to generate individual HTML pages, but I don't seem to be doing it right yet. I do not know (out of hand). But look at the "pydoc" sources. The HTML server version is able to document everything reachable by PYTHONPATH. Surely, you will be able to customize this to restrict it to your product only.
....
Dieter