[PyQt] Qt or PyQt problem?

Phil Thompson phil at riverbankcomputing.com
Thu Jun 4 15:27:33 BST 2009

On Thu, 04 Jun 2009 08:35:52 +0200, "V. Armando Solé" <sole at esrf.fr>
> Phil Thompson wrote:
>> On Wed, 03 Jun 2009 22:57:32 +0200, Vicente Sole wrote:
>>> 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)?
> No, it does not.
> With your patch and changing the returned value of internalId() to 
> quint32 I got it working on 32-bit for both cases, that means, when 
> passing the object and when passing the address of the object. So, I 
> guess internalId() should return an unsigned int32 in a 32-bit platform 
> and an unsigned int64 in a 64-bit platform.
> Changing qabstractitemmodel.sip from:
> qint64 internalId() const;
> to
> unsigned long internalId() const;
> gives correct results for the object case under the platforms I can test.
> For the value case, it works under 32-bit but most likely will fail 
> under 64-bit when the written number cannot be represented by a 32-bit 
> integer.
> I do not know if my "unsigned long" patch can have side effects on other 
> platforms. It makes sense that if one passes an object and the address 
> of the object is stored, one should get back an unsigned of the type the 
> machine is using  for addresses. I always thought it is  unsigned long, 
> but perhaps there are more exotic solutions around. Is it possible to 
> modify qabstractitemmodel.sip set the returned value as quint32 on 
> 32-bit platforms and quint64 on 64-bit platforms? That should solve the 
> issue I am finding without (hopefully) introducing new ones.

I've just uploaded a new snapshot which I hope will fix everything on all


More information about the PyQt mailing list