On Wednesday 15 June 2011 16:37:32 Christian Brugger wrote: > 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)
This is exactly what is done, and the dummy C++ object can cause a lot of undefined behavior to C++ caller as you have seem. > >> 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. -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ PySide mailing list [email protected] http://lists.pyside.org/listinfo/pyside
