[PyKDE] Re: QString vs PyString

[Gerard Vermeulen]

On Fri, 3 Jun 2005 14:50:40 -0700
James Emerton <ephelon at gmail.com> 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.
>
Yes, I agree.  However, I believe that the Qt API is sufficiently
complete that it does not occur with PyQt (except when iterating through
'sentinelled' enums).

If you are writing the WonkString wrapper, you can augment the API so
that your clients can write Wonkstring(WowString("WOW")).  I also like to add
extra constructor arguments to make initialization by calling ..setThis(..),
..setThat(..) superfluous.
> 
> 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.

Doxygen cannot (yet?) parse .sip files; however, the from the 1.4.3
changelist I quote:
"For Developers: Added an abstract interface for language parsers
(see src/parserintf.h), which can be used implement new programming
language parsers. There is also a manager class, where a parser instance
can be bound to a certain file extension."

Personally, I prefer Python doc-strings (but I am a CLI interpreter guy
and think that SGML is a step back from LaTex -- your preferences may
depend on the tools you use).

> 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."
>
Yes, but you loose the functionality of mutable strings.
> 
> 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.
>
It may take you a few hours to implement the conversion between QString
and Python string as a mapped type.  I would not mind missing QString in
my Python code, but I also use Python to prototype and test C++ libraries.
> 
> 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.

Gerard