Re: [igraph] Using iGraph API in Python C module

[Tamas Nepusz]

Dear Chris - 

Sorry for the late reply, I was on the road and I have a terribly long email
backlog now.

> Thanks for the reply. I got a basic sample working that sends the result of
> g.__graph_as_cobject() from Python to C and casts that pointer it an
> igraph_t*. I think this means the pointer reference is borrowed and that
> I can avoid managing de-referencing in the C code but I still need to test
> for memory leaks.
Yes, the pointer is borrowed -- the Python wrapper object is responsible for
destroying the graph when there are no references pointing to the wrapper
object from the Python side. A word of warning: this means that the igraph_t
object will be destroyed once the reference count of the wrapper object on the
Python side drops to zero. If you want to prevent that, you have to Py_INCREF
the wrapper object when you obtain the pointer to the wrapped igraph_t object
and Py_DECREF it when you are done with it.

> I don’t understand the relative advantages of raw_pointer()
> vs graph_as_cobject().
They are functionally equivalent -- I don't even remember why I have
implemented both ;)

> If PyIGraph_ToCGraph() is the preferred method, I wish the igraphmodule_api.h
> was distributed with the iGraph C library so it would be in a standard
> location <igraph/igraphmodule_api.h> .
Unfortunately we cannot do that because the C core of igraph does not (and
should not) "know" anything about any higher level interfaces that are built on
top of it. If we did this, we would have to start distributing similar header
files for the R interface or the Ruby interface as well.

> An alternative would be to provide a function like
> numpy.distutils.misc_util.get_numpy_include_dirs() that returns the install
> path for python iGraph. I think this would make the setup.py for iGraph-based
> extensions more portable.
This is a good idea! I'll check how it is implemented in NumPy and come up with
something similar for igraph. Actually, I took a look at the NumPy source now
and I was wondering: is this function any different from numpy.get_include()?

> trivial examples. I would welcome feedback that improves code quality or
> implements better practices.
Seems fine to me -- my only comment would be that it seems that you ignore any
error codes that igraph functions return, so if something goes wrong within the
igraph_degree() call, you won't be able to detect this. igraph functions almost
always return zero when everything went fine and return the actual result in
one of the arguments, so you can do something like this in most cases:

if (igraph_some_function(g, yadda, yadda) != 0) {
    PyErr_SetString(PyExc_RuntimeError, "igraph blew itself up");
        return 0;
}

This could work in functions that return a PyObject* but not in your
sumDegree() function -- you would have to modify the signature of sumDegree()
to return an int (the error code from igraph) and return the actual result in
an output argument.

All the best,
Tamas