[PyKDE] Re: QString in PyQt4 - Request for Comments

[Michael Thompson]

Phil Thompson wrote:
> I'm wondering whether QString should be dropped in PyQt4 in order to make it 
> more Pythonic.
> 
> At the moment Python strings and unicode strings are automatically converted 
> to QStrings when passed as arguments - so there would be no change there. If 
> a QString was returned by a method or an operator then a unicode string would 
> be returned instead.
> 
> Obviously you would lose all of QString's methods and would have to rely on 
> what Python gives you for manipulating strings.
> 
> One of the limitations of QString has been that you couldn't do...
> 
> q = "Py" + QString("Qt")
> 
> ...but with current snapshots you can - so this is an argument for keeping 
> QString as it has become easier to use.
> 
> BTW, the following is a consequence of the additional support...
> 
> s = "Py"
> # s is of type str
> s += QString("Qt")
> # s is now of type QString
> 
> Comments, opinions welcome.
> 

Given this proposal might have substantial performance implications for 
some classes of application, and given your normal desire to mirror Qt's 
API in pyQt, I'd argue that QString should stay.

Also, what if 'str' was required from a method return value instead of 
'unicode'? That would lead to a chain of conversions: QString -> unicode 
-> str.

No, the goal should be to work away at making QString interacted with 
str/unicode more invisibly/naturally - where possible.

A final thought: one that contradicts what I've just said, but which 
might contribute to the creative process: perhaps 'returned' QString 
objects should be wrapped in an object that simulates a str/unicode? 
There'd still be object creation overhead added to the return process, 
and delegation overhead when methods are called, but no string copy 
overhead.  Still too much overhead?  Still changing the Qt API too much?

--
Mike