[PyKDE] Re: QString vs PyString
phil at riverbankcomputing.co.uk
Sun Jun 5 10:23:25 BST 2005
On Friday 03 June 2005 10:50 pm, James Emerton wrote:
> On 6/3/05, Jim Bublitz <jbublitz at nwinternet.com> wrote:
> > On Friday 03 June 2005 11:40, Matej Cepl wrote:
> > > 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.
> To subtly paraphrase your comment...
> The former provides a lot of problems in documentation, complexity,
> and room for error, and is probably less attractive to people who
> write mixed-API applications using PyQt and C++.
> In my particular usage scenario, there is a huge need for making
> things as simple as possible for people writing the Python. I want to
> empower any given third party (with the appropriate license) to
> leverage our business API and the Qt GUI to customize their
> application. (This is one of three major reasons for incorporating a
> Python interpreter, the other two being development time, and runtime
> Imagine that the target audience is someone who could learn VB in a
> couple weeks. They get access to all our Python code to modify as
> they like, and to learn from for the development of their own modules.
> This is someone that's not going to understand why they get a
> ArgumentError when they write WonkString( someLineEdit.text() ) where
> WonkString() is some C++ function that wants a QString.
> I will concede that this does result in some difficulty with
> documentation. I think that it's a surmountable problem though. I
> believe Doxygen can already parse the embedded Qt documentation. A
> tool that did some translation to more Python appropriate
> documentation, would be a good thing. (I appreciate that someone
> needs to write this part; and it's not exactly glamorous work.
> Eventually, I would probably undertake this myself.)
There are two things here - generating a Pythonic version of the Qt
documentation, or just generating a Pythonic description of the API calls,
arguments and return types. The former is difficult because it still needs
huge amounts of human intervention to edit the text - converting embedded C++
example code to Python, removing unsupported methods etc. The latter is
trvial - SIP already does it for QScintilla API files and I've been meaning
to extend it for automatically generated docstrings and/or html/ReST/XML.
> > 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.
> It seems from the traffic on this list that the primary users of PyQt
> are not C++/Qt developers coming to PyQt, but Python (or newbie)
> developers in need of a better UI than Tk. Those few people writing
> multi-language apps have already cleared a large hurdle in marrying
> Python with another language. I don't think it's a big leap to say
> "There is no QString, all strings are translated to the Python native
> string type."
With the increasing awareness of Python in the KDE community I think you will
see a lot more C++/Qt programmers coming to PyQt/PyKDE.
> Obviously, there is going to be a lot of code out there that relies on
> QString being part of the PyQt API. That means ripping it out by the
> roots would be disastrous. There is also the problem of whether to
> create string or unicode objects. That's why I'd like to do this as a
Then you end up with two incompatible versions of the API. What if a user
wants to run two applications each requiring a different version?
> I am quite willing to make the changes required, but I'm looking for
> feedback because there are people who have more experience at this
> than I do. I'd also like to know if this could be included into the
> PyQt distribution, because nothing sucks more than maintaining a
> modified code base.
I think the best approach is to implement a separate std module. This could be
as comprehensive as you want to make it. You could either fully wrap
std::string or you could just implement it as a %MappedType with convertors
to and from appropriate Python types.
The only problem would be automatically converting a QString to a std::string
in the std module without introducing Qt as a build-time dependency on the
std module. (In theory) I don't have a problem changing SIP to support the
"publishing" of type convertors to other modules. In other words, PyQt
publishes the convertor between a QString and a std::string so that it can be
called by the std module without the latter caring what a QString is.
More information about the PyQt