On Sunday 11 April 2004 8:34 pm, [EMAIL PROTECTED] 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 handles. Phil _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
