[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyQt] =?utf-8?q?unicode=28QChar=29_produces_unexpected_result=3F?=
From:       Phil Thompson <phil () riverbankcomputing ! com>
Date:       2012-08-11 10:28:43
Message-ID: 9ccc67d9a32fd8b25386d6db18adc8fa () localhost
[Download RAW message or body]

On Thu, 9 Aug 2012 13:15:10 -0700, David Cortesi <davecortesi@gmail.com>
wrote:
> To get a python string copy of the contents of a QString object, I have
> been using unicode(some_qstring) .
> 
>>>> qs = QString(u'BAZ')
>>>> len(unicode(qs))
> 3
> 
> So I was surprised when I did the analogous thing to get a
> python string copy of the contents of a QChar.
> 
>>>> qc = QChar(u'Z')
>>>> len(unicode(qc))
> 24
>>>> unicode(qc)
> u'PyQt4.QtCore.QChar(0x5a)'
> 
> It appears to produce the _repr_ value. Is this intended?

It's a side effect of not implementing __unicode__ for QChar. Now fixed.

> Investigating I find that QChar has a unicode() method which
> assistant says returns a ushort.
> 
>>>> qc.unicode()
> 90L
> 
> note the L suffix - is this an artifact of the cpp interface code or
what?

SIP converts all unsigned values to Python long objects. Now fixed so that
shorts and bytes get converted to int objects.

> In the end this is the only way I see to make a QChar into a python
string:
> 
>>>> unicode(QString(qc))
> u'Z'
> 
> Thoughts?

You can now do unicode(qc) as you would expect.

Thanks,
Phil
_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[prev in list] [next in list] [prev in thread] [next in thread]