On 06.04.07 10:44:13, Phil Thompson wrote: > On Friday 06 April 2007 10:10 am, Andreas Pakulat wrote: > > I've put an PyErr_Print(); into the if-part and here's the output (the > > object parsing block is printed when in QtCore the 2nd block with the > > pointer is executed). So as far as I can see the problem is that id() > > returns a long int, but its going to be converted to an int and that > > fails... > > > > emodel>python simpletreemodel.py > > .... > > ------------------------- > > OverflowError: long int too large to convert to int > > ------------------------- > > Object parsing block > > ------------------------- > > OverflowError: long int too large to convert to int > > ------------------------- > > Object parsing block > > ------------------------- > > OverflowError: long int too large to convert to int > > ------------------------- > > Object parsing block > > And I guess if you change the call to PyLong_AsLong() instead of > PyInt_AsLong() then it would call the right overload.
Uhm, no. Just changing the PyInt_AsLong to PyLong_AsLong gives new errors. You know I don't really know what I'm doing here, I have no idea how sip itself works or how wrapping C++ code with sip works... > So the question is... > > Should SIP quietly lose the extra bits, or should it raise an exception. Well, unless I'm mistaken this would still mean that internalId() != id(object), if id() returns a value that is outside the int-range. So I don't think thats a good solution. Unless its possible to make sure id() returns a 32-bit int I don't think there's a proper solution for this, except writing your own way of getting an properly-sized integer for a given object. So a big-fat-warning on the createIndex() and internalId() functions that they don't necessarily work with id() is advised. Also if internalPointer works properly I don't think the id-thing is needed. After all with the pointer you don't necessarily need to keep the list around if you create a tree structure with your objects. Andreas -- You are the only person to ever get this message. _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
