<div class="gmail_quote">On Wed, Nov 17, 2010 at 4:46 PM, Sven Brauch <span dir="ltr"><<a href="mailto:svenbrauch@googlemail.com">svenbrauch@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi!<br><br>I'd like to have inline documentation for python modules, and the ones in your current project. Now, there's a tool called pydoc which creates nice HTML documentation which is also quite suitable to be displayed in the tooltips; looks like this: <a href="http://i.imgur.com/medlL.png" target="_blank">http://i.imgur.com/medlL.png</a><br>


But: It's slow, and it does not have a cache. For example, if I ask for the documentation for the "random" module, it'll take about half a second to generate that, and it doesn't have a cache. And that module isn't really very large... <br>


Plus, I'd also need documentation for custom modules, which will probably be updated frequently.<br><br>So I could use files to cache this data, but I don't really like that idea, because they aren't really well queryable, and it's quite some effort to safely and reliably create and name them. What do you think about using a SQLite database for this? There could be a pre-computed database with documentation for standard modules, and a low-priority documentation worker could be created whenever a custom file is updated.<br>


I'm not sure about this because a) it means the plugin would depend on SQLite (which is probably not *that* bad) but b) the documentation is completely detached from the kdevplatform classes. I'm not sure how screwy b) is, especially as kdevplatform seems to have some pretty advanced documentation management classes already. And, i'd need to extract information like parameters via Regex matching or similar methods. Or customize pydoc to output them seperately (it's easy to modify, as it's written in python).<br>


<br>The alternative would be to create some preprocessed python files which contain pseudocode for the modules and parse them into a DUChain, similar to what the php plugin currently does with it's internal functions file. But this will probably be even slower, and it's more effort to write, and also crappy (because pydoc won't generate that kind of output format by itself).<br>


<br>Also, for the database solution, documentation for modules which are not well documented in pydoc could be added manually or semi-manually.<br><br>What do you think?<br><br>Best regards,<br><font color="#888888">Sven<br>

</font><br>--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
<br></blockquote></div><br><div>Hi Sven!</div><div>I'm really happy to see anyone's interested on that! :) nice.</div><div><br></div><div>I think that it definitely makes sense to have the documentation in a SQLite database, Qt does the same btw and it's not a big burden of a dependency, I'd encourage you to use it.</div>
<div>Regarding the information recollection, I think it's fine to use pydoc instead of actual python parsing (it's what we're doing with Qt also).</div><div><br></div><div>I'll be attentive to your progress.</div>
<div><br></div><div>Aleix</div>