On Wednesday 07 April 2004 9:29 pm, Dave Cuthbert wrote: > A big mea culpa here... > > Phil, earlier we thought that the arguments to PyType_IsSubType() were > switched for subclass converters; I emailed you directly, and you went > ahead and made the change in the SIP tree (post 4.0rc3). > > I think we made another mistake in understanding what SIP was doing. > > In pseudocode form, the original code in rc3 looks like: > > convertSubClass(obj_type, obj) is > ## obj_type is possibly a superclass of obj -- we want to find out > ## the real type of obj > > foreach module in loaded_modules do > if module has subclass_converters then > foreach converter in subclass_converters do > ## attempt conversion > if PyType_IsSubType(obj_type, converter.type) then > converter.convert(obj) > if conversion was successful then return > > > We thought that converter.convert() (scc->scc_converter() in the actual > code) could only convert to converter.type > (scc->scc_basetype->super.type) and would reject attempts to do > otherwise. By this reasoning, the arguments are reversed -- the check > should be seeing if converter.type is a subtype of obj_type for a > potential conversion. > > But that's not the case! What converter.convert() really does is > convert obj to the _most derived type_ of converter.type -- the > IsSubType() check is just making sure the converter is applicable.
Yes. I've reverted the change and added a big comment :) > 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. Phil _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
