On Wednesday 15 June 2011 14:53:15 Thomas Perl wrote:
> Hi,
> 
> 2011/6/15 Christian Brugger <[email protected]>:
> > in the Zen of Python "Errors should never pass silently." PySide could
> > improve in at least two cases:
> > 
> > 1. When deriving a Qt class with virtual methods in Python and
> > forgetting to implement all virtual methods the constructor returns a
> > object containing a Null Pointer which will inevitably cause problems
> > later. This Problem is particularly hard to track down for multiple
> > inheritance where it seems absolutely possible to create a object with
> > partly initialized parent objects. In that case it is very hard to
> > find the error since the object seems to be fully functional in the
> > first place.
> 
> 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.

> 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 :-/
 
Regards

-- 
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
PySide mailing list
[email protected]
http://lists.pyside.org/listinfo/pyside

Reply via email to