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
_______________________________________________
PyKDE mailing list [email protected]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
