Python documentation

[David Nolden]

2010/11/18 Andreas Pakulat <apaku at gmx.de>:
> On 18.11.10 00:54:46, Sven Brauch wrote:
>> Hi,
>>
>> > You could save the time needed to load python and especially to load
>> > the python modules.
>> Python caches them very well. It won't take any relevant amount of time when
>> loading modules for the second time (you can easily try that out in a
>> terminal). :)
>>
>> I'll have a look at the DUChain ItemRepository thingy, thanks for the hint.
>> But I cannot imagine why using SQLite should be so difficult or "fat"...
>
> Its not fat, in fact kdevelop already depends on it (indirectly) through
> the QtHelp plugin.
>
>> it's part of most Qt distributions, isn't it? At least for me, it was
>> available automatically.
>> And I imagined loading and storing things would be like... 2 lines, where do
>> you see a possibility for thousands of lines of code there? If the file ever
>> gets corrupted (which I don't expect to happen, will it?) I can easily just
>> delete it. It's just a cache.
>> Plus, a "real" (sorry :) database would be way more flexible in terms of
>> searching, distributing with predefined data, exporting/importing, ...
>
> Not to mention that duchain has its own set of bugs, including problems
> when the database gets corrupted which can happen by just putting the
> wrong things into it as far as I understood (we still have open
> bugreports because some incorrect data is in peoples duchain and causes
> crashes of kdevelop).

Of course it's a problem when there's unexpected data in the database,
but that's a bug in the code that uses the database, and not in the
database itself. The database is very well tested and stable. I've not
seen a reproducible bug-report in it for years (most problems were
either in the code using the database, or plain file corruptions).
Plus, should we really encounter any problems, then a fix will improve
the stability of the entire application. The more we use it, the
better.

> And the itemrepository stuff is basically maintained by only a single
> person, whereas sqlite is maintained by more people and its also used by
> a far wider range of people.

The problem is not the internals of SQLite, but the interface between
it and KDevelop, and making it interact correctly with sessions etc.

> IMHO sqlite is the right choice for caching some data from pydoc to make
> accessing it faster.

The DUChain itemrepository is _perfect_ for caching, that's basically
all it is about. It's much faster than any SQL-thing, and has less
memory overhead. If it's really only about caching, then a full-blown
database is overkill.

A full SQL database is of course better when it comes to complex
querying, data security, data distribution, etc., but that's not what
a _cache_ is about.

@Sven Brauch:
Of course you're free to use whatever you want, after all the plugin
isn't in KDevelop yet. Anyway I would recommend you to try to use the
ItemRepository as cache now, because it's very fast, has a minimum
amount of overhead, and is already perfectly integrated into sessions
etc, so it should be fast to get it up-and-running.
Should your needs rise above what the ItemRepository delivers, then
you can consider using some more complex database thingy.

Btw. is the python plugin stable for daily usage (eg. doesn't crash)?
I'm also very interested in this plugin, so thank you for working on
it.

Greetings, David