[PyKDE] Re: QString vs PyString

[Phil Thompson]

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
> flexibility.)
>
> 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
> %Feature.

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.

Phil