[PyKDE] QString to Python string conversion trouble

[Phil Thompson]

>===== Original Message From Andreas Gerstlauer <gerstl at ics.uci.edu> =====
>> It's not acceptable to get an exception when applying str() to a QString
>
>Why not? Even in Python itself it is handled like that:

Because unicode() is the only way PyQt has of allowing the programmer to 
convert from QString to a Python Unicode object. My original implementation 
meant that characters >128 raised an exception because it went via a string 
object and the default ascii encoding - but see my later comments.

>>> s = u"Test\u0400Test"
>>> print str(s)
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>UnicodeError: ASCII encoding error: ordinal not in range(128)
>
>> you should get a Python string object with any characters > 128 properly 
escaped.
>>
>If you are dealing with unicode strings you shouldn't use str() on them.
>That's how I understand it is in Python (see above, a Python unicode ist 
*not*
>escaped if passed through str()). A string object can't handle chars > 128.
>If you want those encoded in some other way you'll have to do that manually
>(i.e. via encode()).
>Should that be different in PyQt?
>
>> When I replied originally I was away from my system. When I actually repeat
>> your test I don't get the same result. My transcript is...
>>
>> >>> from qt import *
>> >>> l = "Test\nTest"
>> >>> print l
>> Test
>> Test
>> >>> s = QString(l)
>> >>> print str(s)
>> Test\nTest
>>
>Ok, still, the newline is escape encoded as string "\\n" but not in
>there as real newline.
>
>> >Not in the case of the default ASCII encoding used by unicode() at 
least...
>>
>> unicode() does not use the default encoding.
>>
>Not sure I understand. According to what I read in the Python docs,
>unicode() uses ASCII encoding by default unless given an encoding as second
>parameter. And the ASCII encoding chokes on anything > 128.
>
>> You are basically asking me to restore the previous behaviour - which
>> Boudewijn and Marc-Andre (eventually) convinced me was incorrect.
>>
>No, not really. As far as I understood, the previous behavior was that
>__str__ was returning a Python *string* object with no special handling of
>unicode characters. In that case, 'unicode(QString(u"\u0411\u0412"))'
>won't work.
>What I was saying is that __str__ should return a Python *unicode* object,
>which will then go through the unicode() function unmodified (while the
>str() function converts it automatically). See my "Test" class example
>in the previous mail. Returning a unicode in __str__ works fine.
>
>> As I said - that is not Ok. Also, __str__ has to return a string
>> object. In  Python 2.2 __unicode__ returns a Unicode object.
>
>The solution via separate __str__ and __unicode__ for returning a string
>vs. a unicode in 2.2 is the perfect one, I agree.
>
>However, in versions previous to 2.2, both unicode() and str() call
>the __str__ method. And from what I read, __str__ is allowed to return
>a unicode object. See the following threads:
>  http://mail.python.org/pipermail/python-dev/2000-November/010469.html
>  http://mail.python.org/pipermail/python-dev/2001-January/011799.html

I was unaware of this, and it might be the solution - thanks for the pointer. 
If the __str__ implementation in QString was changed to just return the Python 
Unicode object without converting it again to a string object - would that 
work? Can you test this - I can't get near a system again until Friday.

Thanks,
Phil