GSOC 2010 - Python bindings

From OpenCog

Python bindings Old Work Log

Aug 23

The GSoC program is over now, and I'm happy to say that I have completed most of the project. There is still one important feature (described below) that needs to be implemented, as well as a few other things I would like done with the bindings, and I don't mind continuing to work on them.

I came across one important feature of the bindings that I found out about too late in the summer - it was the conversion from, say, a Python list of Handle() objects (a_list = [Handle(), Handle()], to a C++ vector of Handle() objects (std::vector<Handle>). This would be a very useful feature of the bindings but I unfortunately did not finish this in time - it is a not well-documented feature. I will continue to implement this feature though, as well as adding tests and documentation.

Aug 4

I have so far exposed most of the important classes and data structures to Python, and am now tidying things up, making things more Python-like, and making sure things work correctly (make sure there's no bugs in the bindings). As always, please let me know what you would like to see from the OpenCog C++ API to the OpenCog Python API.

I am not sure it would be feasible to work on a Python shell, for now. I am not sure that I could accomplish such a thing between now and when the program is over (we can try of course). I think it would be a good idea to, after the bindings are done/useful, create a lot of example Python programs that really demonstrate and make use of the framework, so that we'll end up with real and useful OpenCog Python programs that devs can learn from. More specifically, I was thinking of taking all of the C++ code examples (opencog/examples/hopfield, the various Agents in dynamics/attention, code examples found on the wiki, etc.), and making Python equivalents. Doing so will also let me have the benefit of exposing more useful classes that are actually being used (that I may not have previously known). This is just my idea of where I should take my next steps with the Python thing.. let me know what you want.

July 8

I have found that it is not needed to first expose the base classes of a class. The first example of this has been the opencog.server.CogServer class - it is a subclass of Registry<Agent> and Registry<Request>, and yet neither of them are exposed. That should speed things up quite a bit.

There are still things that I'm learning about Boost.Python that need to be applied to the code. For example, the AtomSpace class declared in opencog/atomspace/AtomSpace.h has many overloaded addLink methods, some with default arguments. So you have to combine wrapping overloaded functions with wrapping functions with default arguments. So I still have to learn and apply some tricks.

I feel confident that by the end of next week we'll have working Python examples of starting a server, adding nodes and links, etc.

June 13

I have decided that manual wrapping of the OpenCog framework via Boost.Python would be a good idea, and to proceed fully in that direction. I used SWIG to generate some code but it looked ugly to me and so decided not to use it. I also attempted to use Py++ but could not get it to run successfully on my system. I ended up deciding to wrap with Boost.Python because the framework was already making good use of many other Boost libraries, and this would make a great addition to them. I also delved into it relatively easily, as the tutorials were easy to follow and the code actually worked.

I am now quite used to the mechanics of Boost.Python and have so far exposed most of opencog/atomspace/TruthValue.h . I've made a good example set of code for wrapping various C++ constructs, located in opencog/python/hello .

I have made a branch for the Python bindings on launchpad, located at [1]

May 25

I found out that my job (pretty much) is to understand how to "extend" Python, either manually or with something like SWIG. I think that I will first learn SWIG and then find out later how simple/easy/reasonable/beneficial/useful doing the extending by hand will be. Making a phase 1 accomplishment of the goal using SWIG will allow me to get a more intuitive idea of how to accomplish my goal exactly, with a lot of the hand-holding done by SWIG. This likely will add another dependency to this project, which is bad, and so it will then be thoughtful to see how feasible it would be to remove the dependency, and thus write the bindings by hand, which shouldn't be a pain after learning what SWIG does and how it works.

Links found:

"Extending and Embedding the Python Interpreter" section of the standard Python documentation