On Tuesday 19 September 2006 08:36:31 +0100 (BST), Phil Thompson wrote: Allen Bierbaum wrote:
> > Phil et al: > > > > How much of a lost cause is this? I ask because I just got bit by > > this bug and ate up nearly a day trying to track down a very nasty seg > > fault. As Arve said in the original thread, Model-View programming > > is a core of QT and this issue makes it very difficult to successfully > > program this type of system. I think it is especially relevant to > > PyQT because it is very common to have temporary python wrappers > > hanging around when interfacing with C++ code. I still think that there will be problems with temporary objects, whether in Python or in C++. If you are creating temporary Python wrappers that can presumably have different identities each time they wrap the same underlying object, you still need a way to identify them. To guarantee that the Python wrappers stay around, you may need to ensure that Python owns the objects, and this may interfere with the way the underlying library works. > > In my case I have wrappers around a scene graph (a tree structure for > > computer graphics). Anytime I call through to C++ and ask the tree > > nodes for children or parents, I get a python wrapper back. This > > wrapper is referencing a ref-counted class on the C++ side, but it is > > unique as far as python is concerned. So when I put this into > > internalPointer to retrieve later it immediately goes out of scope in > > python and is invalid when I try to reference it later. This sounds quite like the problems that occur when trying to create a model that exposes QDomDocument, both in C++ and in Python. Unfortunately, the only reasonable approach that didn't take advantage of internal mechanisms in QDomNode was to replicate the structure of the documents using custom item objects. > > If there is any way to make this work I think it would greatly improve > > PyQT. > > It isn't technically possible - unless somebody has a bright idea. I think it might be useful to have a convenience class to help people write models in Python, or at least something to start from. David _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
