[PyKDE] Recent convert's comments

[Markus Stenberg]

On Tue, 9 Jan 2001, Phil Thompson wrote:
> Markus Stenberg wrote:
> > [2] PyQt (and SIP'd stuff in general) explodes _mysteriously_ if you try
> > to do multiple inheritance. I understand the reasons behind this, but at
> > least _I_ couldn't find any reference to it in PyQt documentation, and
> > only way I realized the limitation was by browsing SIP-generated source
> > code.
> It's been on the TODO list for ages to detect when a programmer tries to
> do this. I've added a statement to the docs saying not to do it.

That works, I suppose (i.e. something like assertion if the class cannot
be converted to desired class).

> > I wish there was way to support it as well, but guess it's possible to
> > live without.. (although life's much more difficult - f.ex when
> > implementing custom QSlider-type widget, I wished I could've inherited
> > both QWidget and QRangeControl..)
> It's impossible to support. You'd have to create a new C++ class (and
> the binding to it) dynamically.

How about having separate 'this' elements? I'm not sure if it would work,
but I _think_ that by doing _sip_this_classname approach (and also doing
it for all superclasses, i.e. _sip_QSlider would also have _sip_QWidget,
_sip_QObject).. I'm not sure about the speed, but I don't think it'd be
slower except at instantiation time.

Of course, if no superclass-derived stuff would be used (i.e. all
generated to base level), it wouldn't need to be supported, but that'd
remove some of the functionality.

> >  How is the exception handling done? I noted that my application did not
> > explode totally from exceptions, but instead it seems that each event?
> > performs it's own exception handling, and then resumes event loop on
> > exception.
> I just use the standard Python exception mechanism. Once you enter the
> Qt event loop it then executes bits of Python to respond to events.
> Those bits may raise an exception (and are displayed as normal) but the
> Qt event loop has no idea they are happening.

Nod, the display part was what was nice - because typically, at least in
some of my embedded Python projects, I haven't done any handling at all
- and error winds up terminating process if not handled.

> Phil

-Markus