Basic List content type support in KDevelop-Python

after dealing with a few difficult problems, I finally got a first prototype of the “list content type support” implemented:

Doesn’t look very impressive? It isn’t, yet. But: The plugin now tracks which kind of data a list contains, and when accessing the list in one or another way, it uses that information to guess the type of the resulting objects. This is not very advanced yet, but it will be easy to extend now once the basics are there (and I think it will become very powerful if I can implement all the stuff I’m planning to). One important part of this feature will also be support for fixed-length lists (tuples), so you get correct types for code like

Oh, and one more note: This feature is decorator-based, so all classes with a specific decorator are considered “container” classes. Thus, you can add your own containers by just using the @TypeContainer decorator, and the plugin will track their types.

Apart from adding that feature, I fixed some (more or less severe) bugs since alpha1.1, and the plugin can now parse pypy (one million LoC) without crashing (however it needs quite a few minutes to do so…).

@blindvic: Sven is pretty modest about it, and it sure still needs tons of work and polish, but after having looked into it myself over the last weeks, I think KDev-Python is well on track to beat the other solutions on the market in terms of semantic support for Python – Eclipse, Wing IDE, PyCharm and Microsoft Python Tools for Visual Studio. A lot of what those do is already in KDevelop now to some degree, albeit unfinished. And the KDevelop framework is clearly so strong that progress is pretty swift and the upper limit is far beyond the competition.

That looks really good. Have you considered directly supporting some set of type decorators which people could use to directly on their code to indicate arg types and return types? I've been using this little library to add type info to document my code: https://gitorious.org/twine2/twine2/blobs/master/argvalidate.py It would be great if kdevelop could use this info to.

Also, what would you need in order to support type info for libraries like PyKDE or PyQt?

Hi Simon,yes, I've been thinking about using something like this, but just haven't done it yet. A more important step would be to add automatic recognition of argument types first.For supporting PyQt, you would need to convert the documentation to something readable by the plugin (means, a python script, similar to a header file). This could for example be done by writing some sort of "parser" for http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/classes.html which then outputs several .py files which contain pseudo-class and function definitions with the appropriate docstrings. I've done this for docs.python.org already, it's not terribly difficult.

PyQt actually already ships with an api text file for use by the eric IDE. Since I maintain PyKDE I've got parsers for .sip files and it wouldn't be too hard to use them to format the API data in whatever format you needed.

This was actually not my idea. KDevelop displays it like this, and I'd need to explicitly override it. I don't want to do this, if only for consistency with the other language support plugins (php also uses "unsure").Also, in my opinion "unsure" is more accurate than "mixed", as the item is not a mix between number and string, but one of both and it's not sure which one.

@blindvic: the problem with PyDev is not that it is too hungry for computing resources. The problem is that it is too hungry for "Human attention", like all of Eclipse. I really, really have tried, but it is just too much UI bloat for me, too distracting.

@Eike Hein: right. But that means that the priority now would be polish, so that a first version becomes usable, "good enough". After that we all can dream to conquer the world but please, do not get distracted by too much features because that may cause the polish to be posponed for years.