Don't get me wrong I am not proposing here to fix broken code, I am just suggesting to harden the interface a bit more to prevent silent errors to lead to serious issues later, where they are very hard to track down.
>> Wouldn't the additional checks slow down object creation? I'm not sure >> if it is possible to do the checks at subclassing time (after the >> "class" block has been parsed). > > Right, such check will only slow down the object creation for all objects > while it's only useful for broken code, implement such check seems not to be a > good idea IMO. > Fair enough, after some considerations I think that it is not a good idea to check the availability of virtual methods at class creation. (Something like that would prevent dynamic method creation e.g. with __getattr__ for virtual method.) An alternative would be to check the availability of virtual methods at object creation. However this sounds like a serious overhead and also should be discouraged. I think a good behaviour would be: Try to resolve the method. If that is not possible (AttributeError) print warning and return dummy object to C++ interface. I am quite sure that something like that is already implemented and the error I observed could be related to the dummy object creation mechanism doing something weird. (However to be sure I have filed a bug report) >> There's also a misleading error message (something along the lines of >> "object already deleted") when you forget to call the superclass >> constructor, but I'm not sure if there is anything that we can do >> about this. >> >> > 2. Invalid return types often seems to be unchecked from the Python >> > side and sometimes lead to hard freezes. >> >> Can you create small, self-contained test cases (scripts) out of these >> (as you did in your mail) that one can run and experience the >> problems? When you got that, please file a bug at >> http://bugs.pyside.org/. > > We check return types of virtual functions so a test case would be really nice > to have because it may point us to a bug. > > In the current implementation if the type returned isn't compatible we print a > warning then return a default constructed type back to C++ (NULL pointer if > the returned type is a pointer), we can't just throw a Python error because > virtual functions are called by C++ then we have no idea when nether where the > code will back from C++ to Python so the error could be printed just when the > program ends, IIRC we had a bug about this issue in the past. > > We also return a default constructed type to C++ because we *need* to return > something to C++ and continue with the program flow, we have no choice, this > would lead the program to a crash but if this occur is due to broken Python > code we the binding can't fix broken code :-/ > Thanks for the explanation, there really seems to be something broken with that mechanism. _______________________________________________ PySide mailing list [email protected] http://lists.pyside.org/listinfo/pyside
