[PyKDE] QString in PyQt4 - Request for Comments

[Phil Thompson]

On Wednesday 19 October 2005 1:17 am, David Boddie wrote:
> 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.

It's standard Python behaviour, it's not something I've specifically 
implemented. As Gerard pointed out the same happens with ints and floats.

> > 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?

QString just wouldn't exist in PyQt4.

>  * 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.

This isn't specific to QString - it applies to anything implemented as a 
%MappedType, ie. it's an existing issue. Whether PyQt4 should take Python 
types in signal signatures is another debate...

>  * 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 *.

>  * 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?

>  * QLatin1String and other "restricted" string types - these are something
>    of an implementation detail, but it's worth thinking about how these
>    would be represented.

They wouldn't be wrapped.

> 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.)

> 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.

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.

Phil