From: Bill S. <wf...@sa...> - 2006-03-01 21:03:27
|
If I am developing python wrappers and I do the following: class Graph { Graph(int i) {...} ... } %extend Graph { Graph(PyObject* p) {...} } I get wrappers for both of the constructors, but the first one is "hidden" by the second one, because the dispatch function always calls the second one. I have handled this in the past by writing the %extend constructor to first check for ints, but I am running into some more complicated situations where this approach just doesn't work. Is there a way for the user to tell swig how to assign precedence of argument types? ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** |
From: Marcelo M. <mm...@ac...> - 2006-03-01 23:37:39
|
Try now, there is a patch for the simple cases, but you understand that the problem is that anything is a 'PyObject *', even an 'int' value, therefore you have always a potential conflict. Marcelo Bill Spotz wrote: > If I am developing python wrappers and I do the following: > > class Graph { > Graph(int i) {...} > ... > } > > %extend Graph { > Graph(PyObject* p) {...} > } > > I get wrappers for both of the constructors, but the first one is > "hidden" by the second one, because the dispatch function always > calls the second one. I have handled this in the past by writing the > %extend constructor to first check for ints, but I am running into > some more complicated situations where this approach just doesn't work. > > Is there a way for the user to tell swig how to assign precedence of > argument types? > > ** Bill Spotz ** > ** Sandia National Laboratories Voice: (505)845-0170 ** > ** P.O. Box 5800 Fax: (505)284-5451 ** > ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user |
From: Bill S. <wf...@sa...> - 2006-03-02 00:40:59
|
Right, I understand that everything in python is a PyObject *, but I need those kinds of constructors for accepting general sequences that can be passed to PyArray_ContiguousFromObject(). So, is the idea that PyObject * should have the lowest (highest?) precedent, so that other types always win? I've got to run, so I'll try this tomorrow. Thanks. On Mar 1, 2006, at 4:37 PM, Marcelo Matus wrote: > Try now, there is a patch for the simple cases, but you understand > that > the problem is that anything is a 'PyObject *', even an 'int' value, > therefore you have always a potential conflict. > > Marcelo > > > Bill Spotz wrote: > >> If I am developing python wrappers and I do the following: >> >> class Graph { >> Graph(int i) {...} >> ... >> } >> >> %extend Graph { >> Graph(PyObject* p) {...} >> } >> >> I get wrappers for both of the constructors, but the first one is >> "hidden" by the second one, because the dispatch function always >> calls the second one. I have handled this in the past by writing >> the %extend constructor to first check for ints, but I am running >> into some more complicated situations where this approach just >> doesn't work. >> >> Is there a way for the user to tell swig how to assign precedence >> of argument types? >> >> ** Bill Spotz ** >> ** Sandia National Laboratories Voice: (505)845-0170 ** >> ** P.O. Box 5800 Fax: (505)284-5451 ** >> ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting >> language >> that extends applications into web and mobile media. Attend the >> live webcast >> and join the prime developer group breaking into this new coding >> territory! >> http://sel.as-us.falkag.net/sel? >> cmd=lnk&kid=110944&bid=241720&dat=121642 >> _______________________________________________ >> Swig-user mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-user |
From: Bill S. <wf...@sa...> - 2006-03-02 14:50:40
|
Marcello, The patch seems to be working for me. Thanks. In a related question, what is the preferred method for triggering a python exception from within a new constructor in the %extend block? Calling PyErr_SetString and returning NULL doesn't seem to cut it. On Mar 1, 2006, at 5:40 PM, Bill Spotz wrote: > Right, I understand that everything in python is a PyObject *, but > I need those kinds of constructors for accepting general sequences > that can be passed to PyArray_ContiguousFromObject(). > > So, is the idea that PyObject * should have the lowest (highest?) > precedent, so that other types always win? > > I've got to run, so I'll try this tomorrow. Thanks. > > On Mar 1, 2006, at 4:37 PM, Marcelo Matus wrote: > >> Try now, there is a patch for the simple cases, but you understand >> that >> the problem is that anything is a 'PyObject *', even an 'int' value, >> therefore you have always a potential conflict. >> >> Marcelo >> >> >> Bill Spotz wrote: >> >>> If I am developing python wrappers and I do the following: >>> >>> class Graph { >>> Graph(int i) {...} >>> ... >>> } >>> >>> %extend Graph { >>> Graph(PyObject* p) {...} >>> } >>> >>> I get wrappers for both of the constructors, but the first one >>> is "hidden" by the second one, because the dispatch function >>> always calls the second one. I have handled this in the past by >>> writing the %extend constructor to first check for ints, but I >>> am running into some more complicated situations where this >>> approach just doesn't work. >>> >>> Is there a way for the user to tell swig how to assign precedence >>> of argument types? >>> >>> ** Bill Spotz ** >>> ** Sandia National Laboratories Voice: (505)845-0170 ** >>> ** P.O. Box 5800 Fax: (505)284-5451 ** >>> ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by xPML, a groundbreaking >>> scripting language >>> that extends applications into web and mobile media. Attend the >>> live webcast >>> and join the prime developer group breaking into this new coding >>> territory! >>> http://sel.as-us.falkag.net/sel? >>> cmd=lnk&kid=110944&bid=241720&dat=121642 >>> _______________________________________________ >>> Swig-user mailing list >>> Swi...@li... >>> https://lists.sourceforge.net/lists/listinfo/swig-user |
From: Marcelo M. <mm...@ac...> - 2006-03-02 15:13:43
|
Bill Spotz wrote: > Marcello, > > The patch seems to be working for me. Thanks. > > In a related question, what is the preferred method for triggering a > python exception from within a new constructor in the %extend block? > Calling PyErr_SetString and returning NULL doesn't seem to cut it. hmm, could you provide a small example file to work with it?, probably that is a bug. Marcelo > > On Mar 1, 2006, at 5:40 PM, Bill Spotz wrote: > >> Right, I understand that everything in python is a PyObject *, but I >> need those kinds of constructors for accepting general sequences >> that can be passed to PyArray_ContiguousFromObject(). >> >> So, is the idea that PyObject * should have the lowest (highest?) >> precedent, so that other types always win? >> >> I've got to run, so I'll try this tomorrow. Thanks. >> >> On Mar 1, 2006, at 4:37 PM, Marcelo Matus wrote: >> >>> Try now, there is a patch for the simple cases, but you understand >>> that >>> the problem is that anything is a 'PyObject *', even an 'int' value, >>> therefore you have always a potential conflict. >>> >>> Marcelo >>> >>> >>> Bill Spotz wrote: >>> >>>> If I am developing python wrappers and I do the following: >>>> >>>> class Graph { >>>> Graph(int i) {...} >>>> ... >>>> } >>>> >>>> %extend Graph { >>>> Graph(PyObject* p) {...} >>>> } >>>> >>>> I get wrappers for both of the constructors, but the first one is >>>> "hidden" by the second one, because the dispatch function always >>>> calls the second one. I have handled this in the past by writing >>>> the %extend constructor to first check for ints, but I am running >>>> into some more complicated situations where this approach just >>>> doesn't work. >>>> >>>> Is there a way for the user to tell swig how to assign precedence >>>> of argument types? >>>> >>>> ** Bill Spotz ** >>>> ** Sandia National Laboratories Voice: (505)845-0170 ** >>>> ** P.O. Box 5800 Fax: (505)284-5451 ** >>>> ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting >>>> language >>>> that extends applications into web and mobile media. Attend the >>>> live webcast >>>> and join the prime developer group breaking into this new coding >>>> territory! >>>> http://sel.as-us.falkag.net/sel? >>>> cmd=lnk&kid=110944&bid=241720&dat=121642 >>>> _______________________________________________ >>>> Swig-user mailing list >>>> Swi...@li... >>>> https://lists.sourceforge.net/lists/listinfo/swig-user >>> > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user |
From: Bill S. <wf...@sa...> - 2006-03-02 17:45:03
Attachments:
example.tgz
|
I have attached a tarball that illustrates the problem. You should be able to untar it, cd example, and then type make. After it builds you should run ./testVector.py. The results should be Testing int constructor ... ok Testing sequence constructor ... ok Testing for exception ... ok but you will probably get Testing int constructor ... ok Testing sequence constructor ... ok Testing for exception ... FAIL Vector.{h,cxx} describes a simple vector class with a constructor that takes an int to describe its size and a second constructor that takes an int and a double* to populate it with data. The Vector.i interface file %ignore's the second constructor and replaces it in the %extend block. The %extend block Vector constructor takes a PyObject* and tries to raise an exception when the python object does not describe a sequence of numbers. Note: if you are not using the CVS version of swig, then the first test of the int constructor will raise an exception when the script tries to access the Vector data. On Mar 2, 2006, at 8:13 AM, Marcelo Matus wrote: > Bill Spotz wrote: > >> Marcello, >> >> The patch seems to be working for me. Thanks. >> >> In a related question, what is the preferred method for triggering >> a python exception from within a new constructor in the %extend >> block? Calling PyErr_SetString and returning NULL doesn't seem >> to cut it. > > > hmm, could you provide a small example file to work with it?, > probably that is a bug. > > Marcelo > >> >> On Mar 1, 2006, at 5:40 PM, Bill Spotz wrote: >> >>> Right, I understand that everything in python is a PyObject *, >>> but I need those kinds of constructors for accepting general >>> sequences that can be passed to PyArray_ContiguousFromObject(). >>> >>> So, is the idea that PyObject * should have the lowest >>> (highest?) precedent, so that other types always win? >>> >>> I've got to run, so I'll try this tomorrow. Thanks. >>> >>> On Mar 1, 2006, at 4:37 PM, Marcelo Matus wrote: >>> >>>> Try now, there is a patch for the simple cases, but you >>>> understand that >>>> the problem is that anything is a 'PyObject *', even an 'int' >>>> value, >>>> therefore you have always a potential conflict. >>>> >>>> Marcelo >>>> >>>> >>>> Bill Spotz wrote: >>>> >>>>> If I am developing python wrappers and I do the following: >>>>> >>>>> class Graph { >>>>> Graph(int i) {...} >>>>> ... >>>>> } >>>>> >>>>> %extend Graph { >>>>> Graph(PyObject* p) {...} >>>>> } >>>>> >>>>> I get wrappers for both of the constructors, but the first one >>>>> is "hidden" by the second one, because the dispatch function >>>>> always calls the second one. I have handled this in the past >>>>> by writing the %extend constructor to first check for ints, >>>>> but I am running into some more complicated situations where >>>>> this approach just doesn't work. >>>>> >>>>> Is there a way for the user to tell swig how to assign >>>>> precedence of argument types? >>>>> >>>>> ** Bill Spotz ** >>>>> ** Sandia National Laboratories Voice: (505)845-0170 ** >>>>> ** P.O. Box 5800 Fax: (505)284-5451 ** >>>>> ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** >>>>> >>>>> ------------------------------------------------------- >>>>> This SF.Net email is sponsored by xPML, a groundbreaking >>>>> scripting language >>>>> that extends applications into web and mobile media. Attend >>>>> the live webcast >>>>> and join the prime developer group breaking into this new >>>>> coding territory! >>>>> http://sel.as-us.falkag.net/sel? >>>>> cmd=lnk&kid=110944&bid=241720&dat=121642 >>>>> _______________________________________________ >>>>> Swig-user mailing list >>>>> Swi...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/swig-user |
From: Bill S. <wf...@sa...> - 2006-03-02 17:52:34
Attachments:
example.tgz
|
Here. The previous tarball contained a typo. It didn't bomb on my compiler, but I could see it bombing on others. On Mar 2, 2006, at 10:44 AM, Bill Spotz wrote: > I have attached a tarball that illustrates the problem. You should > be able to untar it, cd example, and then type make. After it > builds you should run ./testVector.py. The results should be > > Testing int constructor ... ok > Testing sequence constructor ... ok > Testing for exception ... ok > > but you will probably get > > Testing int constructor ... ok > Testing sequence constructor ... ok > Testing for exception ... FAIL > > Vector.{h,cxx} describes a simple vector class with a constructor > that takes an int to describe its size and a second constructor > that takes an int and a double* to populate it with data. The > Vector.i interface file %ignore's the second constructor and > replaces it in the %extend block. The %extend block Vector > constructor takes a PyObject* and tries to raise an exception when > the python object does not describe a sequence of numbers. > > Note: if you are not using the CVS version of swig, then the first > test of the int constructor will raise an exception when the script > tries to access the Vector data. > > On Mar 2, 2006, at 8:13 AM, Marcelo Matus wrote: > >> Bill Spotz wrote: >> >>> Marcello, >>> >>> The patch seems to be working for me. Thanks. >>> >>> In a related question, what is the preferred method for >>> triggering a python exception from within a new constructor in >>> the %extend block? Calling PyErr_SetString and returning NULL >>> doesn't seem to cut it. >> >> >> hmm, could you provide a small example file to work with it?, >> probably that is a bug. >> >> Marcelo >> >>> >>> On Mar 1, 2006, at 5:40 PM, Bill Spotz wrote: >>> >>>> Right, I understand that everything in python is a PyObject *, >>>> but I need those kinds of constructors for accepting general >>>> sequences that can be passed to PyArray_ContiguousFromObject(). >>>> >>>> So, is the idea that PyObject * should have the lowest >>>> (highest?) precedent, so that other types always win? >>>> >>>> I've got to run, so I'll try this tomorrow. Thanks. >>>> >>>> On Mar 1, 2006, at 4:37 PM, Marcelo Matus wrote: >>>> >>>>> Try now, there is a patch for the simple cases, but you >>>>> understand that >>>>> the problem is that anything is a 'PyObject *', even an 'int' >>>>> value, >>>>> therefore you have always a potential conflict. >>>>> >>>>> Marcelo >>>>> >>>>> >>>>> Bill Spotz wrote: >>>>> >>>>>> If I am developing python wrappers and I do the following: >>>>>> >>>>>> class Graph { >>>>>> Graph(int i) {...} >>>>>> ... >>>>>> } >>>>>> >>>>>> %extend Graph { >>>>>> Graph(PyObject* p) {...} >>>>>> } >>>>>> >>>>>> I get wrappers for both of the constructors, but the first >>>>>> one is "hidden" by the second one, because the dispatch >>>>>> function always calls the second one. I have handled this >>>>>> in the past by writing the %extend constructor to first >>>>>> check for ints, but I am running into some more complicated >>>>>> situations where this approach just doesn't work. >>>>>> >>>>>> Is there a way for the user to tell swig how to assign >>>>>> precedence of argument types? >>>>>> >>>>>> ** Bill Spotz ** >>>>>> ** Sandia National Laboratories Voice: (505)845-0170 ** >>>>>> ** P.O. Box 5800 Fax: (505)284-5451 ** >>>>>> ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** >>>>>> >>>>>> ------------------------------------------------------- >>>>>> This SF.Net email is sponsored by xPML, a groundbreaking >>>>>> scripting language >>>>>> that extends applications into web and mobile media. Attend >>>>>> the live webcast >>>>>> and join the prime developer group breaking into this new >>>>>> coding territory! >>>>>> http://sel.as-us.falkag.net/sel? >>>>>> cmd=lnk&kid=110944&bid=241720&dat=121642 >>>>>> _______________________________________________ >>>>>> Swig-user mailing list >>>>>> Swi...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/swig-user |
From: Marcelo M. <mm...@ac...> - 2006-03-02 18:16:47
|
Ok, it doesn't seem to be an error. I think the best way for you will be either use %expection or %catches, ie %catches(std::invalid_argument) Vector::Vector; %extend Vector { Vector(PyObject * pySeq) { .... // Type check if (!PySequence_Check(pySeq)) { throw std::invalid_argument(); } ... } or even simpler %exception Vector::Vector { $action if (PyErr_Occurred()) SWIG_fail; } Marcelo Bill Spotz wrote: > Here. > > The previous tarball contained a typo. It didn't bomb on my > compiler, but I could see it bombing on others. > > On Mar 2, 2006, at 10:44 AM, Bill Spotz wrote: > >> I have attached a tarball that illustrates the problem. You should >> be able to untar it, cd example, and then type make. After it >> builds you should run ./testVector.py. The results should be >> >> Testing int constructor ... ok >> Testing sequence constructor ... ok >> Testing for exception ... ok >> >> but you will probably get >> >> Testing int constructor ... ok >> Testing sequence constructor ... ok >> Testing for exception ... FAIL >> >> Vector.{h,cxx} describes a simple vector class with a constructor >> that takes an int to describe its size and a second constructor that >> takes an int and a double* to populate it with data. The Vector.i >> interface file %ignore's the second constructor and replaces it in >> the %extend block. The %extend block Vector constructor takes a >> PyObject* and tries to raise an exception when the python object >> does not describe a sequence of numbers. >> >> Note: if you are not using the CVS version of swig, then the first >> test of the int constructor will raise an exception when the script >> tries to access the Vector data. >> >> On Mar 2, 2006, at 8:13 AM, Marcelo Matus wrote: >> >>> Bill Spotz wrote: >>> >>>> Marcello, >>>> >>>> The patch seems to be working for me. Thanks. >>>> >>>> In a related question, what is the preferred method for triggering >>>> a python exception from within a new constructor in the %extend >>>> block? Calling PyErr_SetString and returning NULL doesn't seem >>>> to cut it. >>> >>> >>> >>> hmm, could you provide a small example file to work with it?, >>> probably that is a bug. >>> >>> Marcelo >>> >>>> >>>> On Mar 1, 2006, at 5:40 PM, Bill Spotz wrote: >>>> >>>>> Right, I understand that everything in python is a PyObject *, >>>>> but I need those kinds of constructors for accepting general >>>>> sequences that can be passed to PyArray_ContiguousFromObject(). >>>>> >>>>> So, is the idea that PyObject * should have the lowest >>>>> (highest?) precedent, so that other types always win? >>>>> >>>>> I've got to run, so I'll try this tomorrow. Thanks. >>>>> >>>>> On Mar 1, 2006, at 4:37 PM, Marcelo Matus wrote: >>>>> >>>>>> Try now, there is a patch for the simple cases, but you >>>>>> understand that >>>>>> the problem is that anything is a 'PyObject *', even an 'int' >>>>>> value, >>>>>> therefore you have always a potential conflict. >>>>>> >>>>>> Marcelo >>>>>> >>>>>> >>>>>> Bill Spotz wrote: >>>>>> >>>>>>> If I am developing python wrappers and I do the following: >>>>>>> >>>>>>> class Graph { >>>>>>> Graph(int i) {...} >>>>>>> ... >>>>>>> } >>>>>>> >>>>>>> %extend Graph { >>>>>>> Graph(PyObject* p) {...} >>>>>>> } >>>>>>> >>>>>>> I get wrappers for both of the constructors, but the first one >>>>>>> is "hidden" by the second one, because the dispatch function >>>>>>> always calls the second one. I have handled this in the past >>>>>>> by writing the %extend constructor to first check for ints, >>>>>>> but I am running into some more complicated situations where >>>>>>> this approach just doesn't work. >>>>>>> >>>>>>> Is there a way for the user to tell swig how to assign >>>>>>> precedence of argument types? >>>>>>> >>>>>>> ** Bill Spotz ** >>>>>>> ** Sandia National Laboratories Voice: (505)845-0170 ** >>>>>>> ** P.O. Box 5800 Fax: (505)284-5451 ** >>>>>>> ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** >>>>>>> >>>>>>> ------------------------------------------------------- >>>>>>> This SF.Net email is sponsored by xPML, a groundbreaking >>>>>>> scripting language >>>>>>> that extends applications into web and mobile media. Attend >>>>>>> the live webcast >>>>>>> and join the prime developer group breaking into this new >>>>>>> coding territory! >>>>>>> http://sel.as-us.falkag.net/sel? >>>>>>> cmd=lnk&kid=110944&bid=241720&dat=121642 >>>>>>> _______________________________________________ >>>>>>> Swig-user mailing list >>>>>>> Swi...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/swig-user >>>>>> > |
From: Marcelo M. <mm...@ac...> - 2006-03-02 18:19:05
|
This setting will pass your test: .... // This will be replaced with %extend below %ignore Vector::Vector(int,double*); %ignore Vector::operator[ ](int); %ignore Vector::operator[ ](int) const; %exception Vector::Vector { $action if (PyErr_Occurred()) SWIG_fail; } %include "Vector.h" .... Bill Spotz wrote: > Here. > > The previous tarball contained a typo. It didn't bomb on my > compiler, but I could see it bombing on others. > > On Mar 2, 2006, at 10:44 AM, Bill Spotz wrote: > >> I have attached a tarball that illustrates the problem. You should >> be able to untar it, cd example, and then type make. After it >> builds you should run ./testVector.py. The results should be >> >> Testing int constructor ... ok >> Testing sequence constructor ... ok >> Testing for exception ... ok >> >> but you will probably get >> >> Testing int constructor ... ok >> Testing sequence constructor ... ok >> Testing for exception ... FAIL >> >> Vector.{h,cxx} describes a simple vector class with a constructor >> that takes an int to describe its size and a second constructor that >> takes an int and a double* to populate it with data. The Vector.i >> interface file %ignore's the second constructor and replaces it in >> the %extend block. The %extend block Vector constructor takes a >> PyObject* and tries to raise an exception when the python object >> does not describe a sequence of numbers. >> >> Note: if you are not using the CVS version of swig, then the first >> test of the int constructor will raise an exception when the script >> tries to access the Vector data. >> >> On Mar 2, 2006, at 8:13 AM, Marcelo Matus wrote: >> >>> Bill Spotz wrote: >>> >>>> Marcello, >>>> >>>> The patch seems to be working for me. Thanks. >>>> >>>> In a related question, what is the preferred method for triggering >>>> a python exception from within a new constructor in the %extend >>>> block? Calling PyErr_SetString and returning NULL doesn't seem >>>> to cut it. >>> >>> >>> >>> hmm, could you provide a small example file to work with it?, >>> probably that is a bug. >>> >>> Marcelo >>> >>>> >>>> On Mar 1, 2006, at 5:40 PM, Bill Spotz wrote: >>>> >>>>> Right, I understand that everything in python is a PyObject *, >>>>> but I need those kinds of constructors for accepting general >>>>> sequences that can be passed to PyArray_ContiguousFromObject(). >>>>> >>>>> So, is the idea that PyObject * should have the lowest >>>>> (highest?) precedent, so that other types always win? >>>>> >>>>> I've got to run, so I'll try this tomorrow. Thanks. >>>>> >>>>> On Mar 1, 2006, at 4:37 PM, Marcelo Matus wrote: >>>>> >>>>>> Try now, there is a patch for the simple cases, but you >>>>>> understand that >>>>>> the problem is that anything is a 'PyObject *', even an 'int' >>>>>> value, >>>>>> therefore you have always a potential conflict. >>>>>> >>>>>> Marcelo >>>>>> >>>>>> >>>>>> Bill Spotz wrote: >>>>>> >>>>>>> If I am developing python wrappers and I do the following: >>>>>>> >>>>>>> class Graph { >>>>>>> Graph(int i) {...} >>>>>>> ... >>>>>>> } >>>>>>> >>>>>>> %extend Graph { >>>>>>> Graph(PyObject* p) {...} >>>>>>> } >>>>>>> >>>>>>> I get wrappers for both of the constructors, but the first one >>>>>>> is "hidden" by the second one, because the dispatch function >>>>>>> always calls the second one. I have handled this in the past >>>>>>> by writing the %extend constructor to first check for ints, >>>>>>> but I am running into some more complicated situations where >>>>>>> this approach just doesn't work. >>>>>>> >>>>>>> Is there a way for the user to tell swig how to assign >>>>>>> precedence of argument types? >>>>>>> >>>>>>> ** Bill Spotz ** >>>>>>> ** Sandia National Laboratories Voice: (505)845-0170 ** >>>>>>> ** P.O. Box 5800 Fax: (505)284-5451 ** >>>>>>> ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** >>>>>>> >>>>>>> ------------------------------------------------------- >>>>>>> This SF.Net email is sponsored by xPML, a groundbreaking >>>>>>> scripting language >>>>>>> that extends applications into web and mobile media. Attend >>>>>>> the live webcast >>>>>>> and join the prime developer group breaking into this new >>>>>>> coding territory! >>>>>>> http://sel.as-us.falkag.net/sel? >>>>>>> cmd=lnk&kid=110944&bid=241720&dat=121642 >>>>>>> _______________________________________________ >>>>>>> Swig-user mailing list >>>>>>> Swi...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/swig-user >>>>>> > |
From: Bill S. <wf...@sa...> - 2006-03-02 21:15:23
|
Thanks. That's what I needed. On Mar 2, 2006, at 11:18 AM, Marcelo Matus wrote: > This setting will pass your test: > > .... > > // This will be replaced with %extend below > %ignore Vector::Vector(int,double*); > %ignore Vector::operator[ ](int); > %ignore Vector::operator[ ](int) const; > > %exception Vector::Vector { > $action > if (PyErr_Occurred()) SWIG_fail; > } > > > %include "Vector.h" > > .... > > Bill Spotz wrote: > >> Here. >> >> The previous tarball contained a typo. It didn't bomb on my >> compiler, but I could see it bombing on others. >> >> On Mar 2, 2006, at 10:44 AM, Bill Spotz wrote: >> >>> I have attached a tarball that illustrates the problem. You >>> should be able to untar it, cd example, and then type make. >>> After it builds you should run ./testVector.py. The results >>> should be >>> >>> Testing int constructor ... ok >>> Testing sequence constructor ... ok >>> Testing for exception ... ok >>> >>> but you will probably get >>> >>> Testing int constructor ... ok >>> Testing sequence constructor ... ok >>> Testing for exception ... FAIL >>> >>> Vector.{h,cxx} describes a simple vector class with a >>> constructor that takes an int to describe its size and a second >>> constructor that takes an int and a double* to populate it with >>> data. The Vector.i interface file %ignore's the second >>> constructor and replaces it in the %extend block. The %extend >>> block Vector constructor takes a PyObject* and tries to raise an >>> exception when the python object does not describe a sequence of >>> numbers. >>> >>> Note: if you are not using the CVS version of swig, then the >>> first test of the int constructor will raise an exception when >>> the script tries to access the Vector data. >>> >>> On Mar 2, 2006, at 8:13 AM, Marcelo Matus wrote: >>> >>>> Bill Spotz wrote: >>>> >>>>> Marcello, >>>>> >>>>> The patch seems to be working for me. Thanks. >>>>> >>>>> In a related question, what is the preferred method for >>>>> triggering a python exception from within a new constructor >>>>> in the %extend block? Calling PyErr_SetString and returning >>>>> NULL doesn't seem to cut it. >>>> >>>> >>>> >>>> hmm, could you provide a small example file to work with it?, >>>> probably that is a bug. >>>> >>>> Marcelo >>>> >>>>> >>>>> On Mar 1, 2006, at 5:40 PM, Bill Spotz wrote: >>>>> >>>>>> Right, I understand that everything in python is a PyObject >>>>>> *, but I need those kinds of constructors for accepting >>>>>> general sequences that can be passed to >>>>>> PyArray_ContiguousFromObject(). >>>>>> >>>>>> So, is the idea that PyObject * should have the lowest >>>>>> (highest?) precedent, so that other types always win? >>>>>> >>>>>> I've got to run, so I'll try this tomorrow. Thanks. >>>>>> >>>>>> On Mar 1, 2006, at 4:37 PM, Marcelo Matus wrote: >>>>>> >>>>>>> Try now, there is a patch for the simple cases, but you >>>>>>> understand that >>>>>>> the problem is that anything is a 'PyObject *', even an >>>>>>> 'int' value, >>>>>>> therefore you have always a potential conflict. >>>>>>> >>>>>>> Marcelo >>>>>>> >>>>>>> >>>>>>> Bill Spotz wrote: >>>>>>> >>>>>>>> If I am developing python wrappers and I do the following: >>>>>>>> >>>>>>>> class Graph { >>>>>>>> Graph(int i) {...} >>>>>>>> ... >>>>>>>> } >>>>>>>> >>>>>>>> %extend Graph { >>>>>>>> Graph(PyObject* p) {...} >>>>>>>> } >>>>>>>> >>>>>>>> I get wrappers for both of the constructors, but the first >>>>>>>> one is "hidden" by the second one, because the dispatch >>>>>>>> function always calls the second one. I have handled >>>>>>>> this in the past by writing the %extend constructor to >>>>>>>> first check for ints, but I am running into some more >>>>>>>> complicated situations where this approach just doesn't work. >>>>>>>> >>>>>>>> Is there a way for the user to tell swig how to assign >>>>>>>> precedence of argument types? >>>>>>>> >>>>>>>> ** Bill Spotz ** >>>>>>>> ** Sandia National Laboratories Voice: (505)845-0170 ** >>>>>>>> ** P.O. Box 5800 Fax: (505)284-5451 ** >>>>>>>> ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** >>>>>>>> >>>>>>>> ------------------------------------------------------- >>>>>>>> This SF.Net email is sponsored by xPML, a groundbreaking >>>>>>>> scripting language >>>>>>>> that extends applications into web and mobile media. Attend >>>>>>>> the live webcast >>>>>>>> and join the prime developer group breaking into this new >>>>>>>> coding territory! >>>>>>>> http://sel.as-us.falkag.net/sel? >>>>>>>> cmd=lnk&kid=110944&bid=241720&dat=121642 >>>>>>>> _______________________________________________ >>>>>>>> Swig-user mailing list >>>>>>>> Swi...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/swig-user >>>>>>> >> > > ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** |
From: Bill S. <wf...@sa...> - 2006-03-20 21:05:29
|
Following Marcelo's advice, my module has been handling exceptions well. What I would like to do now is define a special python exception whose purpose is to indicate that an exception was raised within my module, and use it rather than built-in exceptions such as TypeError or ValueError. If I add %constant PyObject * MyError = PyErr_NewException("MyError"); The resulting wrapper code looks like SWIG_Python_SetConstant(d, "MyError",PyErr_NewException(\"MyError \")); and the compiler complains error: stray '\' in program error: missing terminating " character I thought %define might help, but it did not. Is there a way around this, or is it a bug? On Mar 2, 2006, at 2:14 PM, Bill Spotz wrote: > Thanks. That's what I needed. > > On Mar 2, 2006, at 11:18 AM, Marcelo Matus wrote: > >> This setting will pass your test: >> >> .... >> >> // This will be replaced with %extend below >> %ignore Vector::Vector(int,double*); >> %ignore Vector::operator[ ](int); >> %ignore Vector::operator[ ](int) const; >> >> %exception Vector::Vector { >> $action >> if (PyErr_Occurred()) SWIG_fail; >> } >> >> >> %include "Vector.h" >> >> .... ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** |
From: Marcelo M. <mm...@ac...> - 2006-03-20 21:17:28
|
Fast workaround: %{ #define SWIG_MyError = PyErr_NewException("MyError"); %} %constant PyObject * MyError = SWIG_MyError; Marcelo Bill Spotz wrote: > Following Marcelo's advice, my module has been handling exceptions > well. What I would like to do now is define a special python > exception whose purpose is to indicate that an exception was raised > within my module, and use it rather than built-in exceptions such as > TypeError or ValueError. If I add > > %constant PyObject * MyError = PyErr_NewException("MyError"); > > The resulting wrapper code looks like > > SWIG_Python_SetConstant(d, "MyError",PyErr_NewException(\"MyError > \")); > > and the compiler complains > > error: stray '\' in program > error: missing terminating " character > > I thought %define might help, but it did not. Is there a way around > this, or is it a bug? > > On Mar 2, 2006, at 2:14 PM, Bill Spotz wrote: > >> Thanks. That's what I needed. >> >> On Mar 2, 2006, at 11:18 AM, Marcelo Matus wrote: >> >>> This setting will pass your test: >>> >>> .... >>> >>> // This will be replaced with %extend below >>> %ignore Vector::Vector(int,double*); >>> %ignore Vector::operator[ ](int); >>> %ignore Vector::operator[ ](int) const; >>> >>> %exception Vector::Vector { >>> $action >>> if (PyErr_Occurred()) SWIG_fail; >>> } >>> >>> >>> %include "Vector.h" >>> >>> .... >> > > ** Bill Spotz ** > ** Sandia National Laboratories Voice: (505)845-0170 ** > ** P.O. Box 5800 Fax: (505)284-5451 ** > ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** > > > |
From: Marcelo M. <mm...@ac...> - 2006-03-20 21:25:31
|
If you want your 'own' exception, try using something like: %exception Vector::Vector { $action if (PyErr_Occurred()) { PyObject * myError = PyErr_NewException("MyError"); PyErr_Clear(); PyErr_SetObject(myError,myError); // or use PyErr_SetString // Py_DECREF(myError); //(yes/no ?) SWIG_fail; } } Marcelo Bill Spotz wrote: > Following Marcelo's advice, my module has been handling exceptions > well. What I would like to do now is define a special python > exception whose purpose is to indicate that an exception was raised > within my module, and use it rather than built-in exceptions such as > TypeError or ValueError. If I add > > %constant PyObject * MyError = PyErr_NewException("MyError"); > > The resulting wrapper code looks like > > SWIG_Python_SetConstant(d, "MyError",PyErr_NewException(\"MyError > \")); > > and the compiler complains > > error: stray '\' in program > error: missing terminating " character > > I thought %define might help, but it did not. Is there a way around > this, or is it a bug? > > On Mar 2, 2006, at 2:14 PM, Bill Spotz wrote: > >> Thanks. That's what I needed. >> >> On Mar 2, 2006, at 11:18 AM, Marcelo Matus wrote: >> >>> This setting will pass your test: >>> >>> .... >>> >>> // This will be replaced with %extend below >>> %ignore Vector::Vector(int,double*); >>> %ignore Vector::operator[ ](int); >>> %ignore Vector::operator[ ](int) const; >>> >>> %exception Vector::Vector { >>> $action >>> if (PyErr_Occurred()) SWIG_fail; >>> } >>> >>> >>> %include "Vector.h" >>> >>> .... >> > > ** Bill Spotz ** > ** Sandia National Laboratories Voice: (505)845-0170 ** > ** P.O. Box 5800 Fax: (505)284-5451 ** > ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** > > > |
From: Bill S. <wf...@sa...> - 2006-03-20 21:42:27
|
Actually, I will want to be able to reference the exception in the interface file: %exception { try { $action } catch (int errCode) { PyErr_Format(MyError, "Error code = %d", errCode); SWIG_fail; } } and also allow the python user to reference it as well: try: MyModule.action() except MyModule.MyError: print "Oh well" I thought %constant would help ensure that the new exception would get DECREFed when the module went out of scope. On Mar 20, 2006, at 2:25 PM, Marcelo Matus wrote: > If you want your 'own' exception, try using something like: > > %exception Vector::Vector { > $action > if (PyErr_Occurred()) { > PyObject * myError = PyErr_NewException("MyError"); > PyErr_Clear(); > PyErr_SetObject(myError,myError); // or use PyErr_SetString > // Py_DECREF(myError); //(yes/no ?) > SWIG_fail; > } > } > > Marcelo > > Bill Spotz wrote: > >> Following Marcelo's advice, my module has been handling >> exceptions well. What I would like to do now is define a special >> python exception whose purpose is to indicate that an exception >> was raised within my module, and use it rather than built-in >> exceptions such as TypeError or ValueError. If I add >> >> %constant PyObject * MyError = PyErr_NewException("MyError"); >> >> The resulting wrapper code looks like >> >> SWIG_Python_SetConstant(d, "MyError",PyErr_NewException >> (\"MyError \")); >> >> and the compiler complains >> >> error: stray '\' in program >> error: missing terminating " character >> >> I thought %define might help, but it did not. Is there a way >> around this, or is it a bug? >> >> On Mar 2, 2006, at 2:14 PM, Bill Spotz wrote: >> >>> Thanks. That's what I needed. >>> >>> On Mar 2, 2006, at 11:18 AM, Marcelo Matus wrote: >>> >>>> This setting will pass your test: >>>> >>>> .... >>>> >>>> // This will be replaced with %extend below >>>> %ignore Vector::Vector(int,double*); >>>> %ignore Vector::operator[ ](int); >>>> %ignore Vector::operator[ ](int) const; >>>> >>>> %exception Vector::Vector { >>>> $action >>>> if (PyErr_Occurred()) SWIG_fail; >>>> } >>>> >>>> >>>> %include "Vector.h" >>>> >>>> .... >>> >> >> ** Bill Spotz ** >> ** Sandia National Laboratories Voice: (505)845-0170 ** >> ** P.O. Box 5800 Fax: (505)284-5451 ** >> ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** >> >> >> > > ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** |
From: Bill S. <wf...@sa...> - 2006-03-21 22:23:20
|
My "final" On Mar 20, 2006, at 2:42 PM, Bill Spotz wrote: > Actually, I will want to be able to reference the exception in the > interface file: > > %exception { > try { > $action > } catch (int errCode) { > PyErr_Format(MyError, "Error code = %d", errCode); > SWIG_fail; > } > } > > and also allow the python user to reference it as well: > > try: > MyModule.action() > except MyModule.MyError: > print "Oh well" > > I thought %constant would help ensure that the new exception would > get DECREFed when the module went out of scope. > > On Mar 20, 2006, at 2:25 PM, Marcelo Matus wrote: > >> If you want your 'own' exception, try using something like: >> >> %exception Vector::Vector { >> $action >> if (PyErr_Occurred()) { >> PyObject * myError = PyErr_NewException("MyError"); >> PyErr_Clear(); >> PyErr_SetObject(myError,myError); // or use PyErr_SetString >> // Py_DECREF(myError); //(yes/no ?) >> SWIG_fail; >> } >> } >> >> Marcelo >> >> Bill Spotz wrote: >> >>> Following Marcelo's advice, my module has been handling >>> exceptions well. What I would like to do now is define a >>> special python exception whose purpose is to indicate that an >>> exception was raised within my module, and use it rather than >>> built-in exceptions such as TypeError or ValueError. If I add >>> >>> %constant PyObject * MyError = PyErr_NewException("MyError"); >>> >>> The resulting wrapper code looks like >>> >>> SWIG_Python_SetConstant(d, "MyError",PyErr_NewException >>> (\"MyError \")); >>> >>> and the compiler complains >>> >>> error: stray '\' in program >>> error: missing terminating " character >>> >>> I thought %define might help, but it did not. Is there a way >>> around this, or is it a bug? >>> >>> On Mar 2, 2006, at 2:14 PM, Bill Spotz wrote: >>> >>>> Thanks. That's what I needed. >>>> >>>> On Mar 2, 2006, at 11:18 AM, Marcelo Matus wrote: >>>> >>>>> This setting will pass your test: >>>>> >>>>> .... >>>>> >>>>> // This will be replaced with %extend below >>>>> %ignore Vector::Vector(int,double*); >>>>> %ignore Vector::operator[ ](int); >>>>> %ignore Vector::operator[ ](int) const; >>>>> >>>>> %exception Vector::Vector { >>>>> $action >>>>> if (PyErr_Occurred()) SWIG_fail; >>>>> } >>>>> >>>>> >>>>> %include "Vector.h" >>>>> >>>>> .... >>>> >>> >>> ** Bill Spotz ** >>> ** Sandia National Laboratories Voice: (505)845-0170 ** >>> ** P.O. Box 5800 Fax: (505)284-5451 ** >>> ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** >>> >>> >>> >> >> > > ** Bill Spotz ** > ** Sandia National Laboratories Voice: (505)845-0170 ** > ** P.O. Box 5800 Fax: (505)284-5451 ** > ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** > > ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wf...@sa... ** |