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

[Andrew MacIntyre]

> From: Glynn Clements
 [mailto:glynn at gclements.plus.com]
> Sent: Saturday, 24 April 2010 2:34 AM
> To: Andrew MacIntyre
> Cc: GRASS user list
> Subject: RE: [GRASS-user] Question with Python-SWIG example
> [SEC=UNCLASSIFIED]
> 
> 
> Andrew MacIntyre wrote:
> 
> > > That's what I suspect, namely that the typemap for pointers is
getting
> > > in the way.
> > >
> > > Removing the typemap would mean that you couldn't pass a Python
> > > string, array, buffer, sequence, etc directly to a GRASS function,
but
> > > would have to explicitly allocate and populate a block of memory.
> >
> > I don't think you need to get rid of the typemap - I suspect you
might
> > have to expand it to distinguish between the different types of
pointers
> > though (see below)...
> 
> Yes, but I know how to get rid of it; I don't know how to expand it.
> 
> > > > In the SWIG wrapper?  I see a note about SWIG_ConvertPtr() in
> > > > http://www.swig.org/Doc1.3/Python.html#Python_nn64 ?
> > >
> > > That might help, although I still don't know how to test whether a
> > > given "PyObject *" is a SWIG-wrapped pointer.
> >
> > I get the impression from the above linked documentation that, for
> > example, there should be an explicit typemap reference for CELL
pointers
> > (as returned by Rast_allocate_c_buf()) and that the typemap for CELL
> > pointers as an input argument should use SWIG_ConvertPtr(), which
will
> > set an exception if the inbound object is not a suitable input (if
the
> > exception flag is used; returning NULL will then propagate the
> > exception).  As far as SWIGged pointers go, this seems to be the
closest
> > you can get to Python's *Check* APIs.
> 
> But does that convert arrays, buffers, etc?
> 
> FWIW, the typemaps are in swig/include/python/my_typemaps.i.

I finally had the chance to look at this last night.

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

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.

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.

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

I suspect that the output typemaps change might be easiest to implement.

Cheers,
Andrew.

-------------------------> "These thoughts are mine alone!" <---------
Andrew MacIntyre           Operations Branch
tel:   +61 2 6219 5356     Communications Infrastructure Division
fax:   +61 2 6253 3277     Australian Communications & Media Authority
email: andrew.macintyre at acma.gov.au            http://www.acma.gov.au/


If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents.
 
Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.