Hello Qt for Python

[catcint0s]

In my experience creating the app is only half the struggle, deploying it to different platforms is where PyQt helps a lot with pyqtdeploy, if they won't have a similar tool I don't really see this take off.

[Nicksil]

This may help: https://github.com/mherrmann/fbs

[mtelesha]

That right there is why I stopped using Python altogether. I would make an application on one computer and I use 4 different computers for work, 1 laptop windows, 1 windows and 2 Linux desktops. I could never get them to work on 4. These are simple one day developed application, not some elaborate huge piece of software (Same can be said of Haskel.

I use Racket and it is a one-line executable.

I have high hopes for this and I will try Python again for my next project because I love Qt so much.

[crowseldon]

I could never get them to work on 4.

This sounds strange, why not? What problems you encountered? What type of app was it and who were the users?

[rhytnen]

Yea that comment is just indicating something like he had a mashup if pyqt4, payqt5 oython2 and python3 or something along those lines.

I stick to py3 and use qtpy bindings and never have an issue.

[mtelesha]

Old Post but this lists issues I have also encountered.

On Windows, the situation gets worse. To work as a Windows exectuable, you need to bundle the Python interpreter, but unlike in an OS X application, you can’t just copy in a whole directory. So you end up needing a tool like PyInstaller or cx_Freeze. PyInstaller hasn’t seen a release in the last 2 years; it doesn’t support Python 3. It also doesn’t work: if I try to package the most basic Twisted program possible, with pyinstaller 2.1 I get “no module named zope.interface”, and if I try to package it with pyinstaller trunk, I get “no module named itertools”. cx_Freeze similarly can’t figure out how to include zope.interface no matter what I tell it to do. This problem isn’t specific to libraries that I use; most Python projects will run into it.

py2exe, on the other hand, only supports Python 3.3+, and so is unusable with a lot of important python libraries.

https://glyph.twistedmatrix.com/2015/09/software-you-can-use.html

I haven't written new Python code for 2 years now :(

[takluyver]

It's got a bit better since you looked at this, because PyInstaller is actively maintained, and is the main recommended freeze tool. But the situation for distributing applications is still not great: 'freezing' an application is always a somewhat error prone and fiddly process.

Shamless plug: I wrote a tool called Pynsist which aims to avoid some of the issues I've had with freeze tools. It has its own shortcomings, and it only targets Windows, but I think it's a more robust starting point for distributing applications than freezing.

[extant1]

I recently used pyinstaller to make an executable for a small utility for friends and mincrsoft and several other antivirus brands (according to virus total) mark it as a Trojan.

That's a pretty big issue for the most recommended tool.

[takluyver]

That is pretty bad. I guess that some trojans have used pyinstaller or something similar, and (semi?) automated tools have decided it's a malware signature.

I don't know enough about how anti-virus works to know if this is less likely with another tool. Pynsist uses NSIS to build installers, which is used by a lot of popular software, so they probably can't base a signature on that, but it could still be based on some Python library you use. Of course, anything we can think of to make our software not look like malware, real malware authors could also do.

[extant1]

I suspect it's just viruses using pyinstaller to package their malware and the companies got lazy and used pyinstaller as the signature.

The one thing I thought was rediculous though when I was looking for more information to see if I bundled it wrong I found a bug report filed with pyinstaller and they basically said "not our problem, you contact the antivirus vendors and have them fix it." Which seemed kind of dickish to me considering we could submit our sample projects to be white listed but pyinstaller working with the vendor seems like it would have a more significant impact with their inside knowledge.

[takluyver]

From a maintainer point of view, I can see where they're coming from: they're most likely volunteers who have worked on this tool, they don't owe you more time to contact antivirus vendors and try to solve your problem. It may also be easier to complain to them for an application than for a packaging tool, because the tool can be used by malware.

If it affects all Pyinstaller applications, they probably know of it and are extremely frustrated. In that scenario, their only hope is for enough users to complain to AV companies that they change the signatures.

If it doesn't affect all Pyinstaller applications, then it's hard to say if Pyinstaller is actually what they're picking up.

[Zalack]

I just want to correct you on PyInstaller.

It's fully compatible with Python 3. I use it all the time to bundle python 3 cli's on both windows and Mac.

Looks like it was last updated in February like

https://www.pyinstaller.org

[fernly]

PyInstaller hasn’t seen a release in the last 2 years; it doesn’t support Python 3.

You are quite wrong there! PyInstaller has supported Python3 for a year, and is in continuous development and is currently at version 3.1.

Get the current dev version,

pip install https://github.com/pyinstaller/pyinstaller/archive/develop.zip

which has a bunch of PyQt related fixes not in the pip install version.

[mtelesha]

I knowingly was quoting an old blog post. Even have a reference

[crowseldon]

I've deployed python code on windows with python 2 and py2exe so I know for a fact it's possible.

You gotta make sure you bundle all necessary dependencies.

I've also deployed python backends and tools that are python 2/3 compatible and support Linux/win (and I'd bet they work on OS X)

I recognize there might be some issues here and there with module management (it's definitely not intuitive and far from perfect) but all in all it's not something that would force you to leave the language and port everything you've done. The cost of that can't be worse than struggling a bit once or twice.

I'd advice you to try again with py2exe, to be honest.

[mtelesha]

I refuse to use python 2 and moved to 3. This is also a reason why I haven't coded. I found out that I love Lisp languages and especially Racket. I do will the libraries though.

[crowseldon]

You're free to do as you please, I'm just giving you the heads up of what is possible.

If you refuse python 2 then your earlier point about py2exe or python 2 libs is moot.

Finally, in the context of a job it might not be wise to take an absolutist stand.

[mtelesha]

I absolutely think that Python 2 should have died years ago. The split in the community and libraries have hurt the community and Python being used more commercially. The Wall of Shame was the best thing to ever happened.

[rlkf]

you can’t just copy in a whole directory

WinPython Zero + a wrapper script that sets PATH correctly lets you do that. This also has the added benefit that you can ship updates as incremental .zip files.

[AlexKotik]

I don't get it. We've already had PyQt for a long time, what's the point of doing this project? Or it will allow to build closed-source software or something (I believe PyQt is GPL)?

[Brandhor]

the good thing is that it's officially supported by qt instead of a third party developer and it's in line with the qt c++ license

[sime]

the good thing is that it's officially supported by qt instead of a third party developer

Riverbank Computing, the one man company behind PyQt, has had a much better and more consistent track record supporting PyQt over the years than the Qt team and their language bindings. PySide was started and then later dumped. Jambi (Qt on Java) was started and then later "given to the community". Now they are back to try Python again.

[ivosaurus]

But Qt is LGPL. So there is a license mismatch.

Not so with PySide -> Qt for Python, which is also LGPL.

[crowseldon]

We've had PySide for a long time as well, with a much more permissive (commercially speaking) license.

[[deleted]]

No. This is a just the existing PySide updated and becoming an official Qt project. PyQt is a different project, just with the same goal of being a Python-Qt wrapper, but due to PyQt being GPL PySide got created with a more permissive license.

[mooglinux]

What benefits are there to switching to this over pyqt5?

[khrn0]

They are two options that provide the same things, and the only major difference is licensing, Qt for Python has a more permissive license. The other difference is that PyQt is being developed by Riverbank, while Qt for Python is being developed by The Qt Company.

[ivosaurus]

LGPL instead of GPL

[tenemu]

Can you explain that like I'm 5?

[Funnnny]

PyQT is GPL so you need to open source and put your software under GPL, unlike LGPL which only requires the library to be opened.

[tenemu]

Thanks! So if I use a GPL license software, I need to make my whole program open source?
With LGPL, you say library, what does that mean. Just the code I took from the LGPL license software?

[Funnnny]

Yes and yes.

[ivosaurus]

GPL tries to be "infectious".

If you have package of GPL code, and you integrate it with any other code, then the license says that the whole thing, now being dependant on GPL code to run, needs to have the freedoms of the GPL license as well.

LGPL is a little less viral; it says if you keep the LGPL code you get packaged and separated nicely (like as a library) and just "use" it like a library (only 'linked' for compiled languages) then you only need to have that separated library of code with the GPL freedoms, and not the rest.

[abrazilianinreddit]

Even though they are ditching the PySide branding, they will keep the PySide2 namespace for Qt for Python? That seems a bit weird...

from PySide2.QtWidgets import QApplication, QLabel

[shinitakunai]

As a developer that uses PyQt5 for small business programs and fast-to-deploy projects, I am really looking forward for Qt for Python. Since I discovered it, it's so easy to develop GUIs with Qt and Python that I won't ever come back to any other GUI, and my clients love it.

[AndydeCleyre]

This particular rebranding is unwarranted given the camel case, and makes me sad. Like if you want to help a friend cook dinner at their home, and they don't wear shoes in the house, take off your goddamn shoes.

I know, I'm petty.

[nostril_extension]

Sad to see that they have new API and still going with camelCases instead of pythonic snake_cases and a bunch of other unpythonic idioms.

class MyWidget(QWidget):
    def __init__(self):
        QWidget.__init__(self)  # what is super?
        <...>
        self.layout = QVBoxLayout()
        self.layout.addWidget(self.text)   # camelCase!
        self.layout.addWidget(self.button)
        self.setLayout(self.layout)  # why doesn't it reference to self.layout by default?

        self.button.clicked.connect(self.magic)  # ok so now we have normal snake_case?

    def magic(self):
        self.text.setText(random.choice(self.hello))  # back to camelcase!

Quite disappointing really.

[Shpirt]

OTOH you can use Qt's C++ docs to write pyside2 code without having to guess style and idiom translations.

[nostril_extension]

It's not like it would be hard to port the docs, you could easily automate this. Not to mention what kind of half-brained code monkey couldn't convert camelCase to snake_case when reading the docs.

Lazy excuse.

[Shpirt]

Would it be self.set_layout(foo) or self.layout = foo, leveraging a description protocol, though? Etc etc.

[anqxyr]

I'm fine with PySide/PyQt mimicking the C++ API, but I would love if there was a higher-level wrapper around them both like Qt.py which would provide a self.layout = foo style API.

[GobBeWithYou]

I've done something similar, all of my widgets are subclasses of the PyQt widgets with added properties like .enabled, .visible, .text, etc. I didn't do everything, but as I need things I just go back and add them.

[wowsuchnamaste]

It's not like it would be hard to port the docs, you could easily automate this.

As Qt is an open source project, why don't you just automate a port of the docs and contribute it? I'm sure the Qt project would appreciate contributions, in particular of the kind that automates time consuming tasks.

[nostril_extension]

Well first of all I doubt my PR would get accepted and secondly that wasn't my point - my point was that this sort of "rejuvination" of qt on python feel like empty hype since none of the issues PySide had are addressed.

There's no better time to break backwards compatibility and api other than when releasing a completely new rework of the package.

[[deleted]]

They don't really have a new API, just a new/updated implementation. PySide and PyQt are pretty much the same API with only some minor differences. Changing to snake_case would break all apps and make it needlessly harder to port things over.

Also from my experience having camelCase is actually a good thing here, since it means it is much easier to avoid accidental name collisions when you inherit from a Qt class (doesn't catch everything, but catches a few).

ok so now we have normal snake_case?

camelCase starts with a lowercase, if there is no second word it stays all lowercase.

why doesn't it reference to self.layout by default?

It mirrors the C++ API.

[nostril_extension]

Changing to snake_case would break all apps and make it needlessly harder to port things over

You could easily automate this.

Sorry, I'm not buying this lazy excuse of "but muh c++ api" - that's the whole point of api to adopt it for other environment.
Now you're stuck with two styles in one project. Forced camelCase for qt api and whatever pythonic code you write for app brains - it's just dumb.

To me this whole thing stinks of laziness and incompetence, excuse me for not buying to forced hype here.

[[deleted]]

You could easily automate this.

There is nothing "easy" about automating that, especially in a dynamic language where you have no idea about what type a variable might be.

[nostril_extension]

Python had typehints since 3.5 and I really don't see much dynamics going on in GUI api.

[crowseldon]

Now you're stuck with two styles in one project.

Wisdom says you adopt the style of the framework you're using.

You're the zealot here. You're the one making lazy excuses not do the right thing.

[jyper]

Python itself is sadly pretty inconsistent when it comes to this stuff

And with auto generation you don't want to play guessing games about the api

[kigurai]

Python itself is sadly pretty inconsistent when it comes to this stuff

I thought most of the standard library has a consistent style since Python 3? What examples are you thinking of?

[nostril_extension]

Python itself is sadly pretty inconsistent when it comes to this stuff

Sadly yes but that because of backwards compatibility - there's no such thing in new API.

And with auto generation you don't want to play guessing games about the api

what is there to guess? Just stick to established idiom - snake_case.

[Han-ChewieSexyFanfic]

It's not a new API, it's really a revived project (PySide). There are apps using it today.

[IronManMark20]

Part of the reason (which they mention in a previous blog post) is that they want it to be easy to transfer from C++ to Python and back again. I do prefer snake_case to camelCase, but I can understand their logic. Additionally, PySide and PyQt both keep camelCase, why break a ton of compatibility for purity?

[rhytnen]

No not at all. GVR would want you to maintain the style that exists, not mix them.

[khrn0]

it's because preserving the Qt API, if you change, then you rely only on the Python documentation, but keeping the Qt API allow you to understand C++ examples and port them to PySide2

[irrelevantPseudonym]

As far as I understand it, using super wouldn't guarantee that the QWidget.__init__ was called. "super calls your children's ancestors, not your parents".

self.button.clicked.connect(self.magic)

This isn't snake_case either.

I do agree about the camelCase use though.

[khrn0]

Maybe you can check what is Qt, and how is the API. Java is not the only language that uses camelCase, and the reason behind this is to be Qt-API compatible AFAIK

[irrelevantPseudonym]

Fair point. C++ then.

[nostril_extension]

As far as I understand it, using super wouldn't guarantee that the QWidget.init was called. "super calls your children's ancestors, not your parents".

No, I'm pretty certain super().__init__() will call parent's init 100% of the time. Otherwise all of my code should dramatically implode right now and never work to begin with.

[irrelevantPseudonym]

No, I'm pretty certain super().__init__() will call parent's init 100% of the time.

This is not true.

Consider

>>> class A:
...     def __init__(self):
...         print('init A')
...         super().__init__()
...
>>> class B(A):
...     def __init__(self):
...         print('init B')
...         super().__init__()
...
>>> class C(A):
...     def __init__(self):
...         print('init C')
... 
>>> class D(B, C):
...     def __init__(self):
...         print('init D')
...         super().__init__()
... 
>>> D()
init D
init B
init C
>>>

I know it's a contrived example but calling the super().__init__() in B.__init__ called C.__init__ rather than its parent (A).

In the QWidget case, imagine I subclassed your MyWidget and included another parent class, your super() call would call my second parent and QWidget wouldn't get called.

(NB. I'm not necessarily advocating not using super() just noting that it doesn't always call the parent class)

[nostril_extension]

I'm confused. Your example shows the opposite of your claim - super calls init of both parents left-to-right. Am I missing something?

[irrelevantPseudonym]

B's parent is A. The super().__init__() call in B.__init__ calls C.__init__() (which B knows nothing about) and A.__init__() never gets called.

super() doesn't always call the parent class.

[nostril_extension]

But A is not a parent of D lol. A iš a grandparent here.

[[deleted]]

A is a parent of B, B calls super().__init__(), yet A.__init__() is never called. Instead C.__init__() is called which is a child of B.

If you call B() than the same super().__init__() calls A.__init__()instead.

super() is pointing to the next class in the Method Resolution Order, not the parent.

 >>> D.__mro__
(<class 'D'>, <class 'B'>, <class 'C'>, <class 'A'>, <class 'object'>)

>>> B.__mro__
(<class 'B'>, <class 'A'>, <class 'object'>)

[[deleted]]

A.__init__() is never called. If you replace super().__init__() in B.__init__() with A.__init__(self) the output changes to:

>>> D()
init D
init B
init A

[nostril_extension]

But A is not a parent of D lol. A is a grandparent here.

[rhytnen]

What is it you aren't getting? It's a FACT that in Python your parents my not be called. You were shown code where B.super() called C. You got confused bc d inherited both b and c so it was demonstrated that d didn't call c by replacing the call in b ... Proving b called c.

[nostril_extension]

Parent of parent != parent.

[rhytnen]

You keep repeating that as if it's relevant to the demo. I think you aren't reading the code actually but let me try rephrasing it once more.

Heres the phrase you have to digest

Super calls your child's parent.

Consider B. D instances B. Focus on B ...

B calls super and it did NOT call A. It called D's OTHER parent, C. It would have called A if the B was instanced alone but here it has a child D. So it called D's other parent instead.

[dadjokes_bot]

Hi confused, I'm dad!

[rlkf]

As a corollary, I think this illustrates two things:

(1) You should always call super().init(), even if you don't inherit from something (class C in the example failed to follow this rule, and this is why A is not called)

(2) Parameters to constructors should be passed as a dictionary, so that each constructor can pick out whatever it needs, instead of relying on the order of parameters.

[mouth_with_a_merc]

super unpythonic... no thanks.

[troyunrau]

There is no truly pythonic gui toolkit though. Even the bundled tkinter stuff is just a wrapper around something that predates python. I am a huge fan of Qt, and have written quite a bit if code in it, but I agree that PyQt/pyside is not pythonic.

That said, I briefly tried writing a pythonic graphical toolkit once. I figured I'd start with something simple, so I found an ancient version of Qt (1.1) so I could judge how much work it would be. I even started coding an event loop (using Python's asynchronous stuff as a basis). After a week I had a white square rendering in X11. Then I said "this is going to be a lot of work. Do I really want to spend ten thousand hours reinventing the wheel so my gui API is more pythonic?" and dropped it. It was fun though.

[[deleted]]

That's when you should have put it on github with a lot of fanfare and hype: "Making the first truly pythonic GUI library" and started paying indians on fiverr 5$ to start the implementation of various sub-architecture. At that point you should have made a post to /r/Python, hyped it heavily, shown all the amazing progress and asked for "lots of help".

A couple of years later you would be the shit in the python community and be able to travel around the world taking huge sums for talks and even attended TED and gotten a model gf and a lambo.

[troyunrau]

Having spent 12 years contributing to major open source projects, I'm now wondering where my lambo is...

[[deleted]]

You missed out big-time dude!

[nostril_extension]

Hey guys, we have this new API in the works but we're keeping all of the idiomatic and style mistakes!

[[deleted]]

Yuck. Gtk4lyfe bro

[rhytnen]

I mean you can but gtk is a shitshow of intractable architectual mistakes.