PyQt5 and QString

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

PyQt5 and QString

David Cortesi
I've just got Qt5 and PyQt5 installed and am at the very beginning of
converting some Py2/Qt4 apps to Python 3 and Qt5. Exciting times!

First puzzlement is the removal of QString. I've read the "gotchas"
and the "differences" pages at http://pyqt.sourceforge.net/Docs/PyQt5.
These make it clear that when a Qt class expects a QString input, a
Py3 str type is accepted.

It doesn't explicitly say, but I'm guessing, whenever a Qt method
returns a QString, a Py3 str type is automatically produced...?

And so, there was no need to retain the QString class, just do
everything with the str type ... ?

Please don't take this as criticism. I expect there are good reasons
for the change, but I would like to understand them. Two issues come
to mind. First, if one's PyQt4 code made use of QString methods such
as .isEmpty(), .arg(), or .indexOf(), one now must recode to use
equivalent methods of Python str (approximate equivalent in the case
of .arg(), which is not much like str.format()). What is the benefit
from requiring this recoding, or, what was the penalty of retaining a
QString type for the sake of existing code?

Second thought is performance: does every automatic conversion between
QString and str entail a copy? There are places where my code gets a
QString from one method call, and just hands it along as an input to
another, without any processing. Here's an example:

    book_path = QFileDialog.getOpenFileName(...)
    if not book_path.isEmpty():
        book_info = QFileInfo(book_path)

First, that needs recoding because .isEmpty() is gone. That aside, are
there two memory-to-memory copies of the path string happening there?
Where in PyQt4, it would just be storing and passing a reference to a
QString object?

Thanks for any clarification,

Dave Cortesi
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: PyQt5 and QString

Phil Thompson-5
On 04-01-2014 10:50 pm, David Cortesi wrote:

> I've just got Qt5 and PyQt5 installed and am at the very beginning of
> converting some Py2/Qt4 apps to Python 3 and Qt5. Exciting times!
>
> First puzzlement is the removal of QString. I've read the "gotchas"
> and the "differences" pages at
> http://pyqt.sourceforge.net/Docs/PyQt5.
> These make it clear that when a Qt class expects a QString input, a
> Py3 str type is accepted.
>
> It doesn't explicitly say, but I'm guessing, whenever a Qt method
> returns a QString, a Py3 str type is automatically produced...?

Yes.

> And so, there was no need to retain the QString class, just do
> everything with the str type ... ?

Yes.

> Please don't take this as criticism. I expect there are good reasons
> for the change, but I would like to understand them. Two issues come
> to mind. First, if one's PyQt4 code made use of QString methods such
> as .isEmpty(), .arg(), or .indexOf(), one now must recode to use
> equivalent methods of Python str (approximate equivalent in the case
> of .arg(), which is not much like str.format()). What is the benefit
> from requiring this recoding, or, what was the penalty of retaining a
> QString type for the sake of existing code?

It's more Pythonic to use Python strings than Qt strings.

> Second thought is performance: does every automatic conversion
> between
> QString and str entail a copy? There are places where my code gets a
> QString from one method call, and just hands it along as an input to
> another, without any processing. Here's an example:
>
>     book_path = QFileDialog.getOpenFileName(...)
>     if not book_path.isEmpty():
>         book_info = QFileInfo(book_path)
>
> First, that needs recoding because .isEmpty() is gone. That aside,
> are
> there two memory-to-memory copies of the path string happening there?
> Where in PyQt4, it would just be storing and passing a reference to a
> QString object?

That's correct. However given everything else that is going on to
implement those lines, the two copies are negligible.

Phil
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt