[PyKDE] QString in PyQt4 - Request for Comments

[Simon Edwards]

On Thursday 20 October 2005 03:21, Giovanni Bajo wrote:
> James Emerton <ephelon at gmail.com> wrote:
> 
> > I'm very in favour of the automatic conversion of QStrings into native
> > Python strings.  I always thought that multiple string types was an
> > annoyance exclusive to C++.  I'm also not convinced that performance
> > is a compelling argument for the preservation of QString in Python.
> > See performance data: http://www.gotw.ca/gotw/045.htm
> 
> We're not doing a case about COW-strings (ala QString) vs copied strings. 
We're
> just saying that Qt's QString is COW and there are application and real 
world
> scenario exploiting this feature

If anything, that link shows that we just don't know and can't guess what the 
performance impact is of different strategies for handling strings. Further 
more, anyone trying to optimise their code by using QString instead of 
something had better go collect some imperical data first on what the real 
impact is for their string handling patterns and combination of memory 
allocator, threading etc etc.

The list of open issues looks something like:

	* performance (could be worse, might not be a problem)
	* possible encoding and characterset issues.
	* QStrings are mutable while Python strings are immutable.
	  (I don't know if this causes any real problems, but still...)

If methods like QTextEdit.text() could magically read minds and return a 
Python string or a QString when desired, then everyone would be happy. :-)
Really, what we have in PyQt3 works fine with string except for in the case of 
return types.

We could do something ugly like make QTextEdit.text() return a Python string 
(which is what most people want most of the time), and then add a keyword 
argument "qstring_please" for the case where QString is desired... optimises 
the common case (for people) and makes the not so common case possible...

> In my humble opinion, PyQt should stay as close to C++ Qt as possible. It's 
a
> binding. There are many, many, many places where the Qt API could be made 
more
> Pythonic (just stretch your imagination),

On the other hand, there is the argument that if you want code Qt stuff in a 
C++ kid of way, then maybe you should just use C++.

> but those can find their place in a 
> library which wraps Qt/PyQt with the goal to provide a more Pythonic API.

You want 2 libraries?

How practical is it anyway to replace the Python wrapper of QTextEdit, for 
example, with an extended version (Python code) that adds more Pythonic 
goodness?

cheers,

-- 
Simon Edwards             | Guarddog Firewall
simon at simonzone.com       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."