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