Brett Parker wrote:
Hmmm. Yes, it's central, but a lot of the rest of it works with pydoc - I can see why this particular use case doesn't, but I'll take a looksee tomorrow incase there is an easy solution (I don't think there is, I think Raphael is spot on...)
There isn't really an easy solution, and from what I understand we're making a conscious trade-off; various bits of Django need to access settings in order to bootstrap themselves, and we go through a lot of contortions to put off the need to do so as long as humanly possible (lots of things initially exist only in potentia, as proxy objects or as lazy containers), but sooner or later the settings have to be there or various bits just don't work. This throws a monkey wrench into any attempt at automated analysis of the code.
There is a manual hook -- django.conf.LazySettings.configure() -- which can supply default/dummy values or accept manually-specified values so that bits of Django can be used standalone, but writing a wrapper which would call that before handing off to pydoc would be just as hackish as trying to detect pydoc as the importing module (and would probably also be quite fragile).
Also: upstream, we have a history of leaning WONTFIX on tickets having to do with automated API documentation generators. One of our co-BDFLs has eloquently expressed the opinion that automatic API docs a la pydoc/epydoc are "a poor excuse for not having real documentation" ;)
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
