[PyKDE] Re: QString vs PyString

[James Emerton]

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.)

> 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."

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.

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.