[PyKDE] convertSubClass() -- I introduced a bug :-(
phil at riverbankcomputing.co.uk
Sun Apr 11 22:01:00 BST 2004
On Sunday 11 April 2004 8:34 pm, dacut at neolinear.com wrote:
> Phil Thompson write:
> > On Wednesday 07 April 2004 9:29 pm, Dave Cuthbert wrote:
> >> Now, the real bug is if class A defines a subclass converter, no other
> >> class derived from A can also define a subclass converter (and expect it
> >> to be called consistently). A's subclass converter has to be aware of
> >> the entire hierarchy.
> > Can you explain more? Each converter handles a non-overlapping part of
> > the class tree. They are just called until one of them recognises the
> > object as something it knows the specific type of.
> Right -- the problem is when the converters *don't* handle a
> non-overlapping part of the tree. This doesn't happen in the stock PyQt.
Why would overlapping converters (ie. the same class is handled in more than
one converter) ever be required?
> The reason this has (sort of) happened to us is that we've extended the
> (non-QObject-derived) QCanvasItem classes in C++. QCanvasItem's subclass
> converter, however, only knows about the types defined by Qt directly.
> If subclass converters were allowed to overlap, we could define our own
> converter without modifying the PyQt source directly. This procedure would
> also introduce probably unacceptable overhead.
You *can* provide your own converter that handles only the new classes you
have defined. SIP will try *all* convertors based on the same base class
until one successfully recognises the instance as being of a class that it
More information about the PyQt