[PyKDE] QString vs PyString

[James Emerton]

I am using PyQt as a way to provide UI to scriptable plugins for a
C++/Qt application.  The business end of this app is written in
standard C++ with some usage of boost libraries.  Qt is used
_strictly_ for the UI.  This means that strings in the business logic
are std::string objects (Unicode is not used.)

When using Qt from C++, the QString<->std::string conversion is
automatic.  I don't have to worry about what kind of string I'm using.
 (Apart from minimizing excessive conversions that would lead to a
loss of performance.)

>From within Python, this is not so clean and elegant.  The business
API does not understand what a QString is, and complains of invalid
argument types if I forget to convert the string with str().

So I have two thoughts...

I can alter the std::string MappedType definition to understand
QStrings.  This seems a bit of a hack to me.  The std::string
definition belongs to a module that isn't supposed to know anything
about Qt.  I may need to link the Qt library to this module as well,
which is not desirable.

The other alternative, which I have not had the chance to experiment
with yet, is to use a Feature directive to change the wrapping of
QString to a mapped type.  I'd probably create two versions; one for
unicode.  This seems like the more pythonic way of doing things, but
I'm wondering if I'll run into a lot of issues.


This all leads me to thinking about the strategies used whenan API
targeting one language is wrapped for some other language with
different idioms and culture.  In many cases, utility types (such as
QString, QDate[Time]) have fully capable couterparts native to the
environment in which the developer is using.  What is the advantage to
wrapping these types, as opposed to mapping them to native types?

James