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 _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
