I don't see how losing QString would cause any problems. I always
convert QString objects immediately to a python string using str().
Would it reduce code bloat? It seems like there should be a rule
here. If certain methods take python lists as arguments in place of
QStringList or return a list of QFileInfo instead of a QFileInfoList,
then why are we using QString? Have we discovered a pattern that we
should stick to by now?
I say dump qt objects in favor of python objects wherever possible.
While consistency with the c++ API is nice/important, python is not c+
+, and eventually anyone learning the nuances of using qt with python
is going to get used to a lack of redundant classes. Further, I
always saw pyqt as a total semantic improvement on pure c++ qt, so
keep chopping!
On Oct 18, 2005, at 9:24 AM, 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.
Phil
_______________________________________________
PyKDE mailing list [email protected]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
_______________________________________________
PyKDE mailing list [email protected]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
