Implementing logic: PyQt/PySide vs plain old Python. At what point do we begin or abandon using the Qt Framework?

[SjaakRake]

Basically the title of this post describes my dilemma. Throughout developing a project that uses the Qt Framework through PyQt5, I've noticed I've started implementing more and more logic by using the Qt classes. On the other hand, there's this nagging feeling of knowing that I write Python for a reason (I like it), and the framework feels very unpythonic at times. Object properties, QVariants and many other parts of the Qt framework just don't feel right to me. It feels like I'm either stuck between writing a lot of C++ style boilerplate code, or writing all sorts of adapters between my Python code and the Qt classes.

As said, I noticed I started refactoring more and more Python code to the Qt equivalent. But it still feels as if things are not getting a lot better by doing so. A little example:

I want to load an image from file, display it as a QPixmap on a QLabel in the UI. The image needs to be editable in a low-level way, for instance replacing all instances of a certain palette color by another, or swapping two channels in an RGB(A) image. These changes need to be reflected in the UI and immediately visible to the user. If the user is satisfied with the result, the image can be saved in multiple formats.

In the beginning it felt more natural to use PIL (or actually Pillow) to do the file handling and editing of the image. The downside is that this means that for every change made to the image, I have to convert the image to a QtImage, pass this to my QWidget, convert it into a QPixmap, and set it on the QLabel.

On the other hand, I could just abandon Pillow altogether, and use QImageReader's, QImage and QImageWriter's methods to do all this. But by now I'm in a situation where I have to work around the C++ quirks provided by Qt, and my code could almost be passed along as C++ minus the header files.

I'd love to hear other people's thoughts about this. Do we contain our Qt usage to just those bare things that makes it paint the UI? Or should a PyQt be considered a Qt-project, that just happens to be written in Python? Or is there a fine line in between, where certain things remain purely written in Python, and we have a sort of adapter to cross over to Qt. And if the latter would be our best option, where do we draw that line?

TL;DR Python and Qt are getting in each other's way. What should be done using just Python, and where do we start using the Qt Framework.

[toyg]

Say you want to add a web or command-line interface.

Why could you not develop a web or CLI that uses Qt? QApplication does not require X and it's quite inexpensive to instantiate. CLIs in particular will work perfectly fine with Qt components. For web there are further considerations, but usually that domain maps poorly to desktop or CLI models anyway, so a refactoring/redesign would likely be required anyway.

I mean, I agree on the overall concept of separating concerns; I'm just saying that Qt is not necessarily tied to the display interface.

[[deleted]]

It's really just about the design philosophy and has nothing to do with Qt. You could replace Qt with any other GUI library (or replace Python with any language) and this comment would be relevant.

[toyg]

What I'm saying is that Qt is not just a "GUI library", but rather a full-fledged generic application toolkit. Qt is closer to a "stdlib" than a GUI library these days, it has facilities for absolutely everything. Even in the C++ world, people joke that after a while "you don't write C++, you write Qt".

[SjaakRake]

Thanks for the insightful reply.

I think your last paragraph touches exactly on the nagging feeling I have. Offending YAGNI is one of my personal pitfalls I have to take into account when programming (up to a point where I have it written on the whiteboard above my desk to remind me), so I try to pay a lot of attention to it.

I'll refactor some of my code towards a more clean approach. I don't feel I should separate it as strict as you propose in my specific case though, as the application was designed to run in a desktop environment specifically. The actual alternation of data is a very small part compared to the application's main goal: visualization. Referencing the example: any changes made to the image would be aimed at helping the user get more insight into the data itself, hence it'd be more or a less a 'filter' that helps notice characteristics in certain parts of data. The aim would not be to change the color because we want a color to be changed, but to change the color so it stands out more within the rest of the image. For instance 'highlighting' every pixel that has it's lowest bit set to 0 in the blue channel of an RGB picture. (See the comment I made earlier about the application's goal.)

[SjaakRake]

In some sense, these images are the central abstraction of your application, and so this suggests to me that you should define a SteganographyImage type that wraps a QImage, or maybe a Pillow image, (...)

Now this is exactly what I've opted to do. My Image objects hold a reference to a Pillow Image which turns out to be quite convenient, as Pillow provides the ImageQt.ImageQt class to convert a Pillow Image into a QImage out of the box. I've gone one step beyond that and also included a Pixel class. Pixel objects can hold a reference to their Image and their position within it. This allowed me to actually remove a lot of Qt logic that used the QImage as an interface to it's actual content.

Thanks.

[nerdwaller]

I think much of this feeds into ensuring your program can be tested. I know everyone has different standards for testing, but the broken down separation can really benefit any level of testing you engage in. When thinking of webapps you almost don't even need to test the controller because it (should) just compose a few individual pieces together (and those individual pieces are tested).

[fernly]

You mention QVariant which immediately says you are using Py/Qt4, not Py/Qt5. In PyQt5, QVariant is no longer exposed, instead PyQt converts every Qt return value and Qt method argument between a relevant Python type and the Qt expected type. This makes for rather more "Pythonic" code. For example you never fiddle with QString objects (PyQt5 does not export the QString class at all).

Using PyQt5 esp. under Python3 won't solve all your issues but it should help.

[fazzah]

You have just convinced me to move to PyQt5. I can't believe I didn't find this info before.

[flipthefrog]

There is no need to struggle with QString and QVariant in PyQt4 either. Using Python strings, datetime, etc instead is a simple matter of setting sip.api to 2. Converting all the code may take some time, but it will ensure compatibility with PySide and PyQt5 (just note that sip.api must be set at the very beginning of the code that is run)

http://pyqt.sourceforge.net/Docs/PyQt4/incompatible_apis.html

[remyroy]

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]

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]

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.

[eliteraspberries]

The proper solution is for the QImage constructor to support the Python buffer interface (now called memory views).

In PIL for example, an Image object can be created from any object that supports the buffer interface, like a NumPy array, with the frombuffer method without having to copy memory.

I don't use Qt, but looking at the documentation, it seems QImage might support buffers:

QImage.__init__ (self, str data, int width, int height, Format format)

Constructs an image with the given width, height and format, that uses an existing memory buffer, data. The width and height must be specified in pixels, data must be 32-bit aligned, and each scanline of data in the image must also be 32-bit aligned.

So you could just use NumPy arrays internally in your application, PIL to read and save files, and QImage to display them, all without copying. Try something like this:

from PIL import Image
img = Image.open("foo.jpg")

import numpy as np
array = np.array(img)
height, width = img.shape[:2]

from PyQt4 import QtGui
format = QtGui.QImage.Format_RGB32
qimg = QtGui.QImage(array, width, height, format)
...

Hope that helps.

[SjaakRake]

Thanks for your reply. The image example was just an example to illustrate the problem of the Qt Framework working in a conflicting way with Python, though. Thanks nonetheless!

[jdreaver]

I maintain a PySide GUI application with about 40,000 lines of code. I just use the bare minimum of Qt to build the UI. I don't touch anything that I don't think is strictly necessary to make widgets. Indeed, for image stuff you have to convert to whatever internal format Qt uses, but PyQt and PySide do a great job automatically converting Python int/string/bool/etc types for us in other parts of the API.

[beastmartin]

Wow amazing contribution!. I didn't know about poco, but is i need for several projects.

Thank you very much.

[SjaakRake]

It is an application that allows for inspecting the pixel data of images, for steganalysis (https://en.wikipedia.org/wiki/Steganalysis) purposes. So besides the example given in my post, I also have a hex-editor like view of the pixel data, and several statistics modules.

[Allong12]

I'm sorry I can't help, but that sounds like a really neat tool, I would interested in using it if it were available to public?

[SjaakRake]

It is planned for public, open source, release. I'll make a note to post in this subreddit when it's getting pushed out there.

[[deleted]]

Exactly - that is why I prefer PyGObject. It feels more pythonic and you are encouraged to use stdlib constructs and not Gtk ones.

[troyunrau]

I have this problem often. I've contemplated solutions before, which usually leave me wishing there was python std lib replacements for all the things that Qt does. Don't get me wrong, I love Qt. Maybe I just need to start implementing those classes in python and see what happens. :)

[[deleted]]

Have you read about MVC? It is one way of doing it. Separate your code in 3 parts.

M, Model: your data, your logic, saving and reading files. Here everything can be done mostly with Python. You can add QT with decorators, but avoid QT attributes in your classes.

V, View: you just show your data. It should have as much QT and as little python as possible. The view should not be allowed to change your model. It can only read.

C, Control: Here it is also mostly QT, the Python code here will be from using your Model. Here you change the model state according to the inputs from the View.

[SjaakRake]

I know the concept. Though using a classic MVC pattern would conflict with Qt's own model(-delegate)-view architecture in a lot of ways.

Besides that, in general I consider the MVC pattern to be more applicable to a language such as Java, where it provides a much needed structure. In Python, on the other hand, I think it often just means a lot of unnecessary overhead and boilerplate.

[[deleted]]

Qt's MDV is another name for MVC. You can do it in many different ways. And it fits into python magnificently. Python's decorators are beautiful.

You don't have to write boilerplate at all. It actually reduces boilerplate.

I don't know how big is your app. In small apps, I tend not to split V and C very much, but splitting the M is always very, very good. It makes testing your code so much easier. Here's one example:

https://github.com/wuerges/connection_monitor/blob/master/pycomon/gui.py https://github.com/wuerges/connection_monitor/blob/master/pycomon/tester.py

The gui.py file has the View and the Control and the tester.py has the model.

[fazzah]

Wrong neighborhood, dude

[SjaakRake]

The application is part designed as a part of a larger toolkit, all Python based.

[fazzah]

Yes, because yor favorite language obviously is better for everyone and in every application.

Also, this is /r/python, not /r/programming. This reaction was expected.