On Thu, May 10, 2007 at 13:20:02 +0200, Marco Costalba wrote: > On 5/9/07, Jan Hudec <bulb@xxxxxx> wrote: > >On Wed, May 09, 2007 at 23:09:25 +0200, Fredrik Kuivinen wrote: > >> I have used PyQt for some smaller projects (notably Hgct, a no longer > >> developed > >> commit tool for git and Mercurial. See > >> http://repo.or.cz/w/hgct.git?a=tree). For me > >> PyQt has worked very well. The python interface to Qt is more or less a > >> direct > >> translation of the C++ interface, so the excellent documentation troll > >> tech provides > >> for Qt can be used when developing with PyQt as well. > >> > >> I have never seen the segfaulting you mention. Maybe my programs have > >been > >> too > >> small to trigger that bug... > > > >It's not about size of the programs. It's about having to be careful not to > >refer to widgets inside eg. dialog box from outside and close that dialog > >box. > > In Qt all the classes that ineriths from QObject are memory managed, > to be more clear > you can say that one class is "child" of another class (always > ineritherd from QObject) that becames the parent. > > When you delete the parent, all his children are deleted too, this is > a (big) feature to avoid > missing free() calls for resources created with mallocs() , (well, in > C++ we say 'delete' for resources created by 'new' but the concept is > more or less the same). I know well how it works. And while it is definitely a nice feature in C++ (though it can't beat well done reference-counting smart pointers as Gtkmm has), it is a gross misfeature in any dynamic language. And no, I am not objecting to existence of that system -- it's useful in C++. What I say is, that the PyQt bindings are buggy because it completely fails to make this feature compatible with python memory management - python program should not be able to segfault the interpreter no matter how buggy that program is. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
