[PyKDE] QString in PyQt4 - Request for Comments

[David Boddie]

On Wednesday 19 October 2005 09:47, Phil Thompson wrote:
> On Wednesday 19 October 2005 1:17 am, David Boddie wrote:

> >  * Maintenance of QStrings passed to Python implemented methods -
> > sometimes it's good to keep things in the same form that they were
> > supplied in, although maybe it's not as important for QStrings as it is
> > for, say, QImages.
>
> Examples? It would be possible to add an annotation to SIP, something
> like /GetWrapper/ so that %MethodCode could be given the C++ address as a
> void *.

I can't think of any QString examples. There was a problem with QImages
and ThumbCreators, but that's a different story.

> >  * Codecs - does Python support the same range of codecs as Qt?
>
> As a mono-lingual Brit, that's one of my implied questions - is Python's
> unicode support good enough to be used instead of Qt's?

After a brief desperate search at the Python prompt, I searched the web
for a page with this information and found this:

http://docs.python.org/lib/standard-encodings.html

So it seems that Python may support a superset of codecs. The list of
codecs supported by Qt 4 can be found on this page:

http://doc.trolltech.com/4.0/qtextcodec.html

You would need to ask whether people find themselves handling encoded
text with Python's built-in types rather than with QString and QTextCodec.

> > It would be also interesting to consider whether QStrings could be cached
> > to avoid lots of copying between QString and unicode objects.
>
> While it's easy enough to create a sub-type of the Python unicode type that
> keeps an optional QString copy, I can't see how to make it any easier to
> use than QString. You'd have to create it with some sort of ctor. The
> alternative approach of keeping a separate map of string/unicode objects to
> QStrings gives you problems with garbage collecting the map. (Python
> string/unicode objects don't support weak references.)

Sounds like more trouble than it's worth. :-/

> I've always promoted PyQt's use as a rapid prototyping tool where you
> eventually re-write the prototype in C++ - but I'm not convinced that
> anybody actually does this. With the availability of GPL Qt for Windows I
> hope/expect that there will be many new users for PyQt4 (new to Python as
> well as new to Qt, and with no experience of C++) so eliminating C++isms is
> more important to me now than it has been in the past.

Apart from vague worries about codec support, I suppose the only concerns
I have are about performance and documenting Python-specific behaviour.

David