From: Lisandro D. <da...@gm...> - 2007-08-16 21:53:30
|
Long time ago SWIG changed the way of getting 'this' from objetcs. Originally, it used PyObject_GetAttr, but next it changed to look for 'this' in object's __dict__. Since that change, as I need to use PyObject_GetAttr, I add to my interface files a hack shown below. There is any posibility to get this change go in SIWG. or perhaps better to be included in SWIG python library as a '.i' file I can include in my wrappers to get this behavior? %runtime %{ SWIGINTERNINLINE PyObject* _My_SWIG_GetThis(PyObject* obj) { if (!obj) return NULL; obj =3D PyObject_GetAttr(obj, SWIG_This()); if (!obj) PyErr_Clear(); return obj; } SWIGINTERNINLINE int _My_SWIG_ConvertPtr(PyObject *obj, void **ptr, =09=09 swig_type_info *ty, int flags) { int res =3D SWIG_ConvertPtr(obj, ptr, ty, flags); if (!SWIG_IsOK(res)) { PyObject* _this =3D _My_SWIG_GetThis(obj); res =3D SWIG_ConvertPtr(_this, ptr, ty, flags); Py_XDECREF(_this); } return res; } #undef SWIG_ConvertPtr #define SWIG_ConvertPtr(obj, pptr, type, flags) \ _My_SWIG_ConvertPtr(obj, pptr, type, flags) %} --=20 Lisandro Dalc=EDn --------------- Centro Internacional de M=E9todos Computacionales en Ingenier=EDa (CIMEC) Instituto de Desarrollo Tecnol=F3gico para la Industria Qu=EDmica (INTEC) Consejo Nacional de Investigaciones Cient=EDficas y T=E9cnicas (CONICET) PTLC - G=FCemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 |
From: John L. <jl...@ma...> - 2007-08-17 16:01:36
|
On 08/16/2007 04:53 PM, Lisandro Dalcin wrote: > Long time ago SWIG changed the way of getting 'this' from objetcs. > Originally, it used PyObject_GetAttr, but next it changed to look for > 'this' in object's __dict__. > > Since that change, as I need to use PyObject_GetAttr, I add to my > interface files a hack shown below. > > There is any posibility to get this change go in SIWG. or perhaps > better to be included in SWIG python library as a '.i' file I can > include in my wrappers to get this behavior? > What are you trying to achieve with this code? Could you provide a small example .i file where this is needed? I don't quite understand why... Thanks, John |
From: Lisandro D. <da...@gm...> - 2007-08-17 21:06:26
|
Forgot to CC SWIG-devel ---------- Forwarded message ---------- From: Lisandro Dalcin <da...@gm...> Date: Aug 17, 2007 6:05 PM Subject: Re: [Swig-devel] python: getting 'this' in C To: John Lenz <jl...@ma...> On 8/17/07, John Lenz <jl...@ma...> wrote: > On 08/16/2007 04:53 PM, Lisandro Dalcin wrote: > > Long time ago SWIG changed the way of getting 'this' from objetcs. > > Originally, it used PyObject_GetAttr, but next it changed to look for > > 'this' in object's __dict__. > > There is any posibility to get this change go in SIWG. > > What are you trying to achieve with this code? Could you provide a small > example .i file where this is needed? I don't quite understand why... Well, perhaps my wrapping approach could be seen as a bit of hackery, but let me explain a bit. I develop MPI for Python, a port to MPI. This is constructed as an extension module NOT wrapped with SWIG, but implementing the module using Python C API. Please, note I use the C MPI interface, so there are no classes, just opaque handles and functions. Anyway, I use SWIG for wrapping many other things. So I need a feature: if I pass a Python MPI.Comm object to a SWIG-wrapped function, using the normal SWIG machinery (this), I have a 'property' defined in python, with in fact calls a getter returnin a SWIG handle. My setup is easier to explain with a bit of code:: # import low level C ext mod for MPI # implemented with std Python C API from mpi4py import _mpi # Implement a high-level, class-based API class Comm(_mpi.Comm): # _mpi.Comm is Python C extension type # this class is implemented using ext mod '_mpi', for example: def Get_size(self): return _mpi.comm_size(self) # Yry to use swig support for my class, # for any one wanting to pass a Comm to # SWIG wrapped extensions # This is not required for working only in the Python size # so there should be no need of having SWIG support or # even create a swig handle each time a 'Comm' is instantiated try: form mpi4py import _mpi_swig comm_get_this =3D _mpi_swig.comm_get_this except ImportError: def comm_get_this(self): raise ValueError()'SWIG support not available' # and finally add a property to the class Comm.this =3D property(comm_get_this, doc =3D 'SWIG handle') I hope the code and comments above are clear enough. Please, I am not asking in SWIG to be changed, but to add an optional feature for doing this. As I said, a SWIG '.i' file available in the python library would be enough for me. By using this approach, I can make a non-SWIG module interoperable with other MPI-based modules. like the ones I develop/help to develop por PETSc (large scale linear algebra), SLEPc (large scale eigenvalue problems) and home-made, parallel Finite Element code. -- Lisandro Dalc=EDn --------------- Centro Internacional de M=E9todos Computacionales en Ingenier=EDa (CIMEC) Instituto de Desarrollo Tecnol=F3gico para la Industria Qu=EDmica (INTEC) Consejo Nacional de Investigaciones Cient=EDficas y T=E9cnicas (CONICET) PTLC - G=FCemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 --=20 Lisandro Dalc=EDn --------------- Centro Internacional de M=E9todos Computacionales en Ingenier=EDa (CIMEC) Instituto de Desarrollo Tecnol=F3gico para la Industria Qu=EDmica (INTEC) Consejo Nacional de Investigaciones Cient=EDficas y T=E9cnicas (CONICET) PTLC - G=FCemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 |
From: John L. <jl...@ma...> - 2007-08-22 04:58:19
|
On 08/17/2007 04:05 PM, Lisandro Dalcin wrote: > On 8/17/07, John Lenz <jl...@ma...> wrote: >> On 08/16/2007 04:53 PM, Lisandro Dalcin wrote: >>> Long time ago SWIG changed the way of getting 'this' from objetcs. >>> Originally, it used PyObject_GetAttr, but next it changed to look for >>> 'this' in object's __dict__. >>> There is any posibility to get this change go in SIWG. >> What are you trying to achieve with this code? Could you provide a small >> example .i file where this is needed? I don't quite understand why... > > Well, perhaps my wrapping approach could be seen as a bit of hackery, > but let me explain a bit. > > I develop MPI for Python, a port to MPI. This is constructed as an > extension module NOT wrapped with SWIG, but implementing the module > using Python C API. Please, note I use the C MPI interface, so there > are no classes, just opaque handles and functions. > There is no real requirement that wrapped pointers use the SWIG format for storage in python. You could create a typemap (that overrides the default typemap for SWIGTYPE) that stores the data in the MPI format. The SWIG pointer representations (that is, those created with SWIG_NewPointerObj and SWIG_ConvertPtr) are just there for when no other format is known or in use. If you do it this way, then pointers generated by SWIG could be passed to MPI code that uses the Python C API directly. For these pointers, they are not stored in the SWIG format but directly in whatever format MPI uses. So just provide in and out typemaps that read and write the MPI format directly, and completly ignore SWIG_NewPointerObj and SWIG_ConvertPtr. Pointers that are only passed to back and forth to the SWIG module will still work just fine, just be in a different underlying format. Hope that makes sense... John |
From: Lisandro D. <da...@gm...> - 2007-08-22 20:52:21
|
On 8/22/07, John Lenz <jl...@ma...> wrote: > So just provide in and out typemaps that read and write the MPI format > directly, and completly ignore SWIG_NewPointerObj and SWIG_ConvertPtr. > > Pointers that are only passed to back and forth to the SWIG module will > still work just fine, just be in a different underlying format. > > Hope that makes sense... Yes, it makes a lot of sense. But this way, another user, using SWIG and my module, have to write an ad-hoc typemap to get back the underlying MPI handle. If I provide the standard, default 'this' object, then then the user only have to write his/her '.i' interface file like the following: %types(MPI_Comm) // normally not needed void some_fun_using_comm(MPI_Comm, ....) Then, if the user pass my 'MPI.Comm' class, providing 'this' as an attribute accessed via a property, the the wrapped code works out-of the box. I am only asking for SWIG to extend the way it looks for 'this' object. Currently, it searchs only in the object's '__dict__'. What I ask for is the following: if 'this' is not found in 'obj.__dict__', the try once more to get it using the C equivalent of getattr(obj, 'this'). The use of 'getattr' was the SWIG behavior some time ago. Next it was changed to look in '__dict__' (I remember this explanation: ... it confused PyLucene...). Can you see any potential problem of SWIG using 'getattr' if 'this' is not found in 'obj.__dict__' ? --=20 Lisandro Dalc=EDn --------------- Centro Internacional de M=E9todos Computacionales en Ingenier=EDa (CIMEC) Instituto de Desarrollo Tecnol=F3gico para la Industria Qu=EDmica (INTEC) Consejo Nacional de Investigaciones Cient=EDficas y T=E9cnicas (CONICET) PTLC - G=FCemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 |