[PyKDE] QString in PyQt4 - Request for Comments

[Patrick Stinson]

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    PyKDE at mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
>