On 05/13/2013 01:12 AM, David Cortesi wrote:
That is not IMO a good design choice. At least if toPlainText returns a const QString reference, one can then use r/o QString methods like count(), contains(), indexOf etc, without penalty. Also one could provide it to a QRegExp, e.g.:j = qre.indexIn( myEditor.toPlainText() ) while j >= 0 : # ...do something with qre.cap(0)... j = qre.indexIn( myEditor.toPlainText() , j )
It seems to me that a rhetorical question is appropriate here: Why are you using *Py*Qt if you aren't using python regular expressions (and generally valuing the Python non-gui bits over the Qt non-gui bits)? Qt is an amazing library, but in PyQt code I personally have virtually never used a Qt choice when there was a corresponding Python choice. And this mode of thinking is why I suspect that the alleged performance hit is not really an issue because most people have *preferred* the Python string. I suspect that the performance you gain by staying as much as possible with-in the Qt toolset is traded for performance you gain by getting in the Python toolset ASAP to do the stuff which made you choose Python.
Joel _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
