<div dir="ltr"><div>Thanks to you and Mathias for the prompt replies.<br><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im">
>     docstring = unicode( myEditor.toPlainText() )<br>
</div>In PyQt5 toPlainText() will return a str object for Python3 and a unicode<br>
object for Python2.<div></div></blockquote><div><br></div>And, as Mathias says, it is a copy?...<br><div>That is not IMO a good design choice. At least if toPlainText<br>returns a const QString reference, one can then use r/o QString<br>

</div><div>methods like count(), contains(), indexOf etc, without penalty.<br></div><div>Also one could provide it to a QRegExp, e.g.:<br><br></div><div>    j = qre.indexIn( myEditor.toPlainText() )</div><div>    while j >= 0 :<br>

</div><div>        # ...do something with qre.cap(0)...<br></div><div>        j = qre.indexIn( myEditor.toPlainText() , j )<br></div><div><br></div><div>This is more or less the patther of a syntax highlighter<br></div><div>

as well as other possible applications -- and it<br></div><div>would be a catastrophe with a large doc when every<br></div><div>toPlainText call does a new memcopy.<br><br></div><div>In short, I urge you to leave the conversion to Python str<br>

</div><div>in the programmer's hands, e.g. via unicode() or str().<br><br></div><div>Or, find a way to support those "STL-style iterators"<br>that are currently omitted...?<br></div><br>> Also in regard to making intensive loops faster<br>

> how well do PyQtx calls integrate with Cython or PyPy?<br><br></div><br></div></div>