[PyKDE] QString in PyQt4 - Request for Comments

[David Boddie]

On Tue, 18 Oct 2005 18:24:08, Phil Thompson wrote:

> I'm wondering whether QString should be dropped in PyQt4 in order to make
> it more Pythonic.

On one hand, it sounds like a nice idea. It would mean that you don't
have to think about manually converting the ones you think you'll need
and keeping track of the ones you don't. On the other hand, the idea of
dropping it makes me feel uneasy for reasons I'll talk about below.

> At the moment Python strings and unicode strings are automatically
> converted to QStrings when passed as arguments - so there would be no
> change there. If a QString was returned by a method or an operator then a
> unicode string would be returned instead.
>
> Obviously you would lose all of QString's methods and would have to rely on
> what Python gives you for manipulating strings.

I took another look at the QString API in Qt 4 to see whether this would be
all that bad. There are a few functions there that provide in-place
operations on strings and, although there are no exact equivalents for
Python strings, they probably aren't all that relevant in Python.
The same is possibly true of conversion functions like toDouble() and
fromDouble().

> One of the limitations of QString has been that you couldn't do...
>
> q = "Py" + QString("Qt")
>
> ...but with current snapshots you can - so this is an argument for keeping
> QString as it has become easier to use.

Yes, this is much better.

> BTW, the following is a consequence of the additional support...
>
> s = "Py"
> # s is of type str
> s += QString("Qt")
> # s is now of type QString

This looks strange, but makes some kind of sense if you consider QString
to be a more general string type than Python strings.

> Comments, opinions welcome.

There are a few areas where we'd need to think about the consequences
a bit more, or at least try experimenting with a Pythonic implementation,
before deciding whether the suggested behaviour would be an improvement.

Off the top of my head, I think we should consider the following things:

 * Translation with tr() - would it return a QString or a Python
   unicode string?
 * The types of arguments emitted with signals and the types of values
   received in slots - declaring arguments as "const QString &" then
   getting a unicode string might be a bit confusing.
 * 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.
 * Codecs - does Python support the same range of codecs as Qt?
 * QLatin1String and other "restricted" string types - these are something
   of an implementation detail, but it's worth thinking about how these
   would be represented.

It would be also interesting to consider whether QStrings could be cached to
avoid lots of copying between QString and unicode objects.

Personally, I don't see the problem with having strings arrive in Python
functions or methods as unicode objects, but I'd like to see QString kept
around for familiarity.

I think that there are two groups of people who expect different things, and
QString is possibly controversial to many people because it's peculiar to see
a class that duplicates the functionality of a built-in type. However, I
think that there's an advantage in being able to write code in Python that
resembles what you would write in C++. This applies to other classes that
would appear to duplicate Python built-in types.

David