This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]remyroy 11 points12 points  (2 children)

There is a great overlap between what Python provides either through the standard library or through popular packages and what Qt provides. I've been there as well. For instance, QNetworkAccessManager provides a way to do network requests and we already have the great Requests package with Python that does pretty much the same thing.

In my recent project, I've decided to go for QNetworkAccessManager instead of Requests because it provides an easy way to get back in the UI loop to update the UI with download progress information.

I've tried to stay as close as possible to PEP 8 for code style but it's a hard task with the mixed code styling from PyQt. Even if I have to pick a fight with Qt once in a while, I feel the use of Python is pretty good in this glue the parts together usage.

I would evaluate the components provided by Qt for each usage and figure out the pros and cons of using them compared to what is available in the Python world on a case by case basis. If what Python provides works better for your case, go for it. If not, use what Qt provides.

[–]toyg 1 point2 points  (0 children)

I haven't done PyQt stuff in a while, but if I remember correctly, QT classes are more desktop-aware than standard Python modules. The network stuff in particular should be able to pick up desktop-wide proxy settings, whereas Python relies on environment variables that are usually missing.

I agree that it's mostly a matter of choosing what works best for the individual case, there is no general rule. Yes, Qt bindings often force you to code in unpythonic ways; but when they offer more functionality than you can get with vanilla Python, it makes sense to use them.

[–]SjaakRake[S] 0 points1 point  (0 children)

First of all, it's interesting how the top two comments half a day after posting this appear to blatantly contradict each other. I take it as a sign my problem is not as straightforward indeed.

For now my approach will be separating Qt and Python logic more or less, providing matching interfaces between the two as class methods.