[PyQt] Qt or PyQt problem?

Phil Thompson phil at riverbankcomputing.com
Wed Jun 3 22:14:59 BST 2009


On Wed, 03 Jun 2009 22:57:32 +0200, Vicente Sole <sole at esrf.fr> wrote:
> Quoting Darren Dale:
> 
>> On Wed, Jun 3, 2009 at 2:40 PM, Darren Dale <dsdale24 at gmail.com> wrote:
>>
>> One last point, however: I think Armando's suggestion of passing the
>> object,
>> and not the object's id(), coupled with Phil's patch, is the right
>> solution:
>>
> 
> At my side, passing the object was already fine on 64-bit without  
> Phil's patch. It is under 32-bit that the check has to be made.
> 
> If I have understood Phil's patch, it tries to set a long into an  
> unsigned 32bit. Darren has already found it does not work under 64 bit  
> for the case of passing the address of the object.
> 
> Since Trolltech already decided not to fix their bug, I would just  
> leave the things as they are concerning PyQt. The alternative of  
> passing the object works as it should in most cases. The cases where  
> retrieving the object address via the call to internalID() fail are  
> easy to catch because at the python side one receives a negative  
> number when one is expecting a positive number and it can be converted  
> as in the example I sent previously.
> 
> createIndex can accept a pointer or a quint32 so, in any case one  
> would say it is a positive number. Perhaps forcing the return of  
> internalId() to be a quint64 instead of qint64 in  
> qabstractitemmodel.sip could do the job, but then we would not be  
> respecting the (incorrect) Qt API.
> 
> So, unless I get I successful test under 32-bit with Phil\'s patch, I  
> would just leave the things as they are.

Except that this keeps coming up.

Does changing the type of internalId() from qint64 to quint64 solve the
problem (I don't have a 32 bit Linux system handy)?

Phil


More information about the PyQt mailing list