On Friday 03 June 2005 11:40, Matej Cepl wrote: > James Emerton wrote: > > 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? > > And why do you have to use QString at all? Cannot you just use Python's > native strings/unicode strings? Read more about the relationship between > Python's and Qt-string machinery read > http://www.opendocs.org/pyqt/index.lxp?lxpwrap=c2029%2ehtm
Because a lot of Qt/KDE methods return a QString. I view it as a difference in philosophy between simply providing an interface from Qt to Python vs. writing a Python-based API based on Qt. The latter provides a lot more problems in documentation, complexity and room for error, and is probably less attractive to people who write mixed-language applications using Qt and PyQt. I find it annoying to have to use str() or s.latin1(), but over all I prefer a minimum of tampering with the Qt API. Jim _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
