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

image_size = 800, 600
x, y = image_size # it should know that x, y are ints

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…).

Have Fun, and feel free to email me about problems.

Categories: Everything

Tags: , ,

16 replies

  1. Thanks for that. I've been waiting for python support in kdevelop for so long…

  2. Thank you so much again 🙂

  3. So, does this mean, KDevelop has autocomplete (with introspection) for Python?
    I am looking for an alternative for PyDev and Eclipse – they too hungry for resources…

  4. @blindvic Yes — see my previous post. It's not complete yet, tough; it works, but it's missing a lot of bonus features (like the one in this post).

  5. @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.

  6. Oh, this is wonderful!
    So far I'm really happy with PyCharm (paid the license), yet I'd love to see Open Source solutions picking up advanced code intelligence! 😀

    Keep up the good work!

  7. 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: 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?

  8. 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 which then outputs several .py files which contain pseudo-class and function definitions with the appropriate docstrings. I've done this for already, it's not terribly difficult.

  9. Hello,

    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.

  10. Hi,

    oh, cool! Where can I find those scripts and files? I'd really like to take a look at them.


  11. Hi,

    It is all the stuff I use to keep PyKDE updated:

    There are some parsers in there, and also some unit tests. and are interesting for you.

  12. Hi,

    okay, thanks. I'll try to use that as soon as I got a few other things sorted out.


  13. Little idea: instead of "unsure (float, string)", how about displaying "mixed (float, string)"?

    I think it more accurately reflects the situation, and is a less 'unsure' statement to begin with 🙂

  14. 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.


  15. Very cool, at last Python support is nearing!

    @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.

    @Simon Edwards: All fine and good, but basics first (see above)

    Way to go Sven!

Leave a Reply

Your email address will not be published. Required fields are marked *