AutoComplete in C++ Editor for Python
davea at ieee.org
Sun May 3 21:14:13 CEST 2009
flamz3d at gmail.com wrote:
> I am embedding python support in my C++ application and was looking at
> adding "Intellisense" or "AutoComplete" support.
> I found a way to do it using the "dir" function, but this creates a
> problem. Here's why. Let's say I have the following code in my editor:
> import sys
> x = sys
> Now, I would like to get all attributes of the object called 'x'. I
> can "instrument" the code and add "print dir(x)" at the end,
> temporarily redirect the python output to a string and execute the
> But this is not safe: I do NOT want to execute the code while the user
> is typing!
> Is there a way to "compile" the python code and get access to the
> symbol table from that compiled block?
> Did anybody ever implement AutoComplete in a editor for Python?
Several editors for Python support auto-complete, to one extent or
another. The only one I have experience with is Komodo. Komodo runs in
a separate process, so it doesn't suffer from the problems of having two
gui event-loops in the same process, and other similar problems. It
also won't be executing code that might have side effects in the child
The downside is that in order to do auto-complete, it has to figure it
out from other clues. From the docs, and from reading, and from
experiementing, I believe that it uses two approaches. One approach is
a set of language files which try to describe all the symbols in the
standard language and library. They have one for each release (2.4,
2.5, ...) Theoretically, you could add your own for other libraries.
Second approach is to parse the code that's visible to it. That parsing
is well done, and surprisingly quick, but there are lots of tricks a
developer might use that can fool it. For example, wxPython lets you
import just one symbol, and lots more appear magically. It's no big
deal, they have code structured one way, but the interface is very
different. Catch is that code completion frequently gets fooled by these.
I'd point out that if you do walk the dictionaries at run time, you'll
get different results when you do it with nothing running than if you do
a strictly static analysis. So some things might only show up if you've
stepped into the function with the magic going on.
Simplest example I can come up with of something a static analysis won't
spot: An instance object obj may have some number of attributes
assigned the the __init__() method. But it could also have new fields
added by anyone with a referent into it.
There is a Python parser in module ast. Perhaps that'd be some help.
I've not used it, so can't give you any specifics.
More information about the Python-list