Python documentation

[David Nolden]

2010/11/17 Sven Brauch <svenbrauch at googlemail.com>:
> Hi!
>
> Thank you very much for your answers.
>
> Well David, it's not only about speed; I also consider it extremely
> inelegant to waste CPU time for virtually nothing. There's really no reason
> to generate documentation for a module 20.000 times a day when there's no
> chance it'll ever change... plus, progress indicators are very nice, but
> being fast enough to leave them out is always nicer. :) Also, for some
> modules like QtGui, it takes about 30 seconds to generate documentation; of
> course, you don't want to show all that in a tooltip, but maybe the
> sub-packages listed there, and being able to load those from a databse is
> much nicer than yet another pydoc hack. But I agree, waiting for 0.5 seconds

Well, how do you fill the database? It will also require a kind of
pydoc, so the question is just: Is it better to add 50 lines of code
in the pydoc plugin, or is it better to add a thousand of lines of
code to KDevelop, plus an additional "fat" dependency, which is
SQLite.

With the database, you will have the typical load of work like always
with databases. Where to store it? What about multiple running
instances? Is the database corrupted? Is the entry you're requesting
still current? And then bugs, bugs bugs. I have experience with this
because we used a separate database in KDevelop3 for the code model.

We already maintain a database, which is the duchain storage, so if
you consider a database as a cache, then it should be that one. It is
much more efficient than any SQL database, and already has perfect
integration with KDevelop, so you won't have to worry about any of the
points above (except for the "Is the entry still current"). You can
easily use a duchain ItemRepository as a database, as is done in many
components. Take a look at kdevplatform/language/duchain/uses.h /
uses.cpp, there you have a fully working simple single-key database.
You just have to copy it over, change the names, and change the data
types. For example, you could map from IndexedQualifiedIdentifier to
any set of Indexed.... types you add to the "UsesItem" successor, plus
a dynamic list of the item type you add through the APPENDED_LIST_...
stuff.

> I considered keeping the python scripts running for the parser, too, but I
> dismissed it because it's simply not worth it. The only thing you could save
> with that is time needed for startup; which is actually only needed once
> because python caches stuff very well (and also keeps semi-compiled versions
> of the script around, so it's not even reparsed).

You could save the time needed to load python and especially to load
the python modules. I don't know where most of the time is wasted
though, so maybe this wouldn't help much.

Greetings, David