[GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]

Glynn Clements glynn at gclements.plus.com
Tue May 4 00:48:48 EDT 2010


Andrew MacIntyre wrote:

> I think the issue is that pyobj_to_ptr() in my_typemaps.i is expecting
> the SWIGged pointer as a Python CObject (though it does seem odd that a
> pointer object, previously returned from a SWIGged call, being passed in
> is at least accepted without a ValueError - which suggests that these
> objects are at least "look" like CObjects to Python).
> 
> I would suggest that this isn't correct unless you can determine that
> SWIG is definitely generating CObjects to contain returned pointers (I
> couldn't find anything to suggest this).

The support for CObjects isn't critical; it was really just a case of
"what Python types can reasonably be converted to a pointer?".

> In the case where SWIG is using its own objects to contain returned
> pointers, then I expect pyobj_to_ptr() needs to be changed to use
> SWIG_ConvertPtr() rather than PyCObject_AsVoidPtr() to retrieve the
> actual pointer, or the output typemaps for returned pointers need to be
> changed to use Python's CObjects rather than native SWIG wrapper
> objects.

So, what do you suggest? Remove the PyCObject_Check() call, explicitly
check for string, read buffer, write buffer, and sequence, then call
SWIG_ConvertPtr() on anything which is left over?

> Several other approaches occur to me:
> - use simple SWIG typemaps for the various pointer types and create
> helper functions which translate from Python objects to GRASS data
> structures and vice versa.  It might be possible to use ctypes objects
> too, though that could be quite tricky as I couldn't find any direct API
> support.

IOW, strings, lists, arrays, etc would need to be converted
explicitly? That's inconvenient, but I personally consider the issue
of what's possible to be more important than what's simple. If the
typemaps make certain things impossible, they should go, even if that
makes other things less convenient.

> - go to the trouble of actually creating full Python object wrappers for
> the various data structures and use them exclusively instead of using
> thinly wrapped pointers (this has the potential advantage that memory
> management becomes a lot more automatic for the user).
> 
> - ditch SWIG completely for Python and use ctypes exclusively.
> 
> The ctypes approach is the one I myself would take, but I acknowledge
> there are downsides - the potential for sub-optimal performance in
> certain cases and the cost of initially generating the wrapper
> definitions being the most obvious.

The problem isn't initial generation, but maintenance. If someone
changes a structure, enum, prototype, etc in the headers, it's
unlikely that they'll remember to change any ctypes wrapper to match.

> I haven't tried the gccxml based
> code generator that ctypes author Thomas Heller created, which might
> make the job a lot easier if it works on the GRASS headers.

If ctypes wrappers can be generated automatically from the headers,
that solves the problem. Manually generated ctypes wrappers have to be
kept in sync, while SWIG wrappers tend to be hard to use (mostly due
to inadequate documentation).

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-user mailing list