Re: unable to retrieve python exception type objects (C api)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: unable to retrieve python exception type objects (C api)

Samuel DEBIONNE
Hi,

Sorry to reopen this old thread, I just wanted to let you know that this
bug is still in 4.19.8. The issue is with SIP file that defines an
exception and is shared between a couple of different modules.

Thanks,

Sam

On 21 Apr 2017, at 1:13 pm, Philip Scott wrote:

 > Hi Folks,
 > > According to the documentation online: SIP generates a Python
object > for each exception defined with the %Exception directive. > >
These objects are named with the fully qualified exception name (i.e. >
including any enclosing scope) prefixed by sipException_. For > example,
the type object for enum Except defined in class Klass >
issipException_Klass_Except. > > The objects of all imported exceptions
are available to handwritten > code. > > This worked for us well in
4.17. I am trying to upgrade to 4.19 and > came across a problem. In
4.19, for a SIP module called say, 'foo,' > there is an #define in
sipAPIfoo.h of the form > > #define sipException_my_exception
sipExportedExceptions_foo[0] > > However, the array
sipExportedExceptions_foo is defined in > 'sipfoocmodule.cpp' but not
declared in any header file. > > I managed to work around this in one
module by simply declaring it > before my handwritten C code: > > extern
PyObject *sipExportedExceptions_foo[3]; > > But unfortunately got
completely stuck when I came a cross a SIP file > that was shared
between a couple of different modules as the name of > the module it was
going to be used in could not be known. The code > looks a bit like this
(I believe it was also taken from the PyQt > example documentation
somewhere): > > %Exception std::exception(SIP_Exception)
/PyName=StdException/ { > %TypeHeaderCode #include <exception> %End
%RaiseCode const char* what > = sipExceptionRef.what();
SIP_BLOCK_THREADS > PyErr_SetString(sipException_std_exception, what); >
SIP_UNBLOCK_THREADS %End }; > > I wonder if this is related to the
incompatibility notes from the > 4.19 release: > > Starting with this
version only those type structures needed by the > generated code are
automatically available to handwritten code > possibly resulting in
compiler errors. Handwritten code should be > changed to call
sipFindType() to obtain a pointer to the required > type structure. > >
I did try using sipFindType to find my exception type but with no >
success, and looking at the generated code I can't see anywhere that >
the exceptions are registered in any way except in the python module >
dictionary. > > Apologies if this question has been asked already - I
did do a quick > ctrl+f of the post titles to the mailing list; I
couldn't find a > better way to search. I've been googling for a solid
day, I can't > believe this hasn't affected anyone else - perhaps our
usage is > non-standard in some way? > > Anyhow, any pointers would be
greatly appreciated.


_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: unable to retrieve python exception type objects (C api)

Phil Thompson-5
On 7 Mar 2018, at 1:02 pm, Samuel DEBIONNE <[hidden email]> wrote:
>
> Hi,
>
> Sorry to reopen this old thread, I just wanted to let you know that this bug is still in 4.19.8. The issue is with SIP file that defines an exception and is shared between a couple of different modules.

Works for me. A test that demonstrates the problem please.

Phil

> On 21 Apr 2017, at 1:13 pm, Philip Scott wrote:
>
> > Hi Folks,
> > > According to the documentation online: SIP generates a Python object > for each exception defined with the %Exception directive. > > These objects are named with the fully qualified exception name (i.e. > including any enclosing scope) prefixed by sipException_. For > example, the type object for enum Except defined in class Klass > issipException_Klass_Except. > > The objects of all imported exceptions are available to handwritten > code. > > This worked for us well in 4.17. I am trying to upgrade to 4.19 and > came across a problem. In 4.19, for a SIP module called say, 'foo,' > there is an #define in sipAPIfoo.h of the form > > #define sipException_my_exception sipExportedExceptions_foo[0] > > However, the array sipExportedExceptions_foo is defined in > 'sipfoocmodule.cpp' but not declared in any header file. > > I managed to work around this in one module by simply declaring it > before my handwritten C code: > > extern PyObject *sipExportedExceptions_foo[3]; > > But unfortunately got completely stuck when I came a cross a SIP file > that was shared between a couple of different modules as the name of > the module it was going to be used in could not be known. The code > looks a bit like this (I believe it was also taken from the PyQt > example documentation somewhere): > > %Exception std::exception(SIP_Exception) /PyName=StdException/ { > %TypeHeaderCode #include <exception> %End %RaiseCode const char* what > = sipExceptionRef.what(); SIP_BLOCK_THREADS > PyErr_SetString(sipException_std_exception, what); > SIP_UNBLOCK_THREADS %End }; > > I wonder if this is related to the incompatibility notes from the > 4.19 release: > > Starting with this version only those type structures needed by the > generated code are automatically available to handwritten code > possibly resulting in compiler errors. Handwritten code should be > changed to call sipFindType() to obtain a pointer to the required > type structure. > > I did try using sipFindType to find my exception type but with no > success, and looking at the generated code I can't see anywhere that > the exceptions are registered in any way except in the python module > dictionary. > > Apologies if this question has been asked already - I did do a quick > ctrl+f of the post titles to the mailing list; I couldn't find a > better way to search. I've been googling for a solid day, I can't > believe this hasn't affected anyone else - perhaps our usage is > non-standard in some way? > > Anyhow, any pointers would be greatly appreciated.
>
>
> _______________________________________________
> PyQt mailing list    [hidden email]
> https://www.riverbankcomputing.com/mailman/listinfo/pyqt

_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt