[Development] Technical vision for Qt for Python
jhihn at gmx.com
Mon Aug 19 17:55:45 CEST 2019
Thanks Cristián! If you thought I was suggesting it was done, I was not. I was just stating the facts as they appear at the current time feedback is being given. :-) I am encouraged at PySide continuing development!
I hope that the private destructor issue is avoided for all future classes. I don't know how Qt can enforce that though, but Qt6 provides a great opportunity to make the API change. Can Qt set a "no private destructor!" rule?
About the event loop, 1 official solution is preferred over 2 contrib solutions. ;-) Just like with my choosing to use PySide then finding classes I needed were not supported, I will always chose wrong the first time! LOL.
The Jupyter notebook suggestion really is a minor issue AFAIAC, it's where Qt could really shine and pick up some users. (Interactive Qt+Jupyter notebooks? Amazing!) But it in no way factors into my day-to-day.
When those dev changes land in a release I'll take a look again, or if I get something that doesn't require them, I'll see about giving it a go.
The only remaining concerns I have are about QtCreator's integration. The .pyproject format is extremely limited. Proper python project packaging, FTW. (Say that 4 times fast!) I have python purists that I work with that I have to appease (and they use the asyncio event loop too!)
In my day-to-day I don't really care that it is in C++. But I care that I can do what I set out to do. That's my benchmark. That's got me in C++. But I'm also eagerly awaiting for the time I can interop with my python coworkers!
> Sent: Monday, August 19, 2019 at 10:36 AM
> From: "Cristián Maureira-Fredes" <Cristian.Maureira-Fredes at qt.io>
> To: "development at qt-project.org" <development at qt-project.org>
> Subject: Re: [Development] Technical vision for Qt for Python
> Hello Jason,
> I will comment inline.
> On 8/19/19 3:52 PM, Jason H wrote:
> > I tried PySide 2, and was extremely disappointed that not all the classes are supported. What's worse it PyQt supports the classes that are not supported. Having that kind of errata is devastating to the confidence in a project. Qt6/PySide6 must have parity from day 1.
> This is true, we still have missing bindings,
> but you skipped the good part of the issue you had:
> - You reported a couple of missing classes,
> - We verify that's specific case, and we discover it was due to Private
> destructor not supported by our binding generator.
> - This led to start fixing this issues on the Qt Multimedia module,
> that ended app on PYSIDE-1041 being related to QTBUG-74422 which was
> merged on dev
> So we are truly addressing all the concerns by our users.
> Concerning the missing bindings, we have been publicly listing them
> all, and even comparing them with PyQt5:
> There are many things that make little sense in Python land,
> and other classes from which we don't have a use-case, or we are not
> aware of how critical for a project could be.
> That's why we need your feedback.
> > Next, the biggest flaw is lack of Python 3 native event loop integration. A lot of people have codebases Python 3 event loops now, PySide should be seamless from day 1.
> It would be really nice to have a proper integration,
> but this is a difficult implementation, and not even PyQt5 has it
> natively, that's why at the moment we have an open task from which
> you can find two external plugins so interact with the Python event
> loop, asyncqt, and quamash: https://bugreports.qt.io/browse/PYSIDE-769
> I tend to think that technologies should coexist better,
> rather than choosing one or another, and since there are so many
> things being improve in the QML side, I would expect to see the
> goodies from Qt6 first to analyze how we could improve the experience
> using Python.
> We are always open to people trying new things,
> maybe somehow has some ideas of adding Python to the scene,
> or even improve the current PySide2/QML interaction.
> > Jupiter concerns me. I'm wondering how well we can get Qt to integrate with Jupiter notebooks? Can we get interactive Qt in the notebook? (WASM?)
> I got contacted by Jupyter developers, because there is a lot of
> interest to better integrate Qt in their notebooks, but of course,
> this is not a straightforward task.
> We would love to see how things can change in future releases.
> > Finally, I've used PyQt off and on since Qt 3.3 days. I really like Python as a language to use Qt in a rapid prototype development way, but the limitations stated above prevent it from being my default environment.
> Since both statements have workarounds and future solutions,
> we are looking forward to hear what else is missing and stopping you
> to use the module.
> Thanks for your comments,
> > (snip)
> >> Sent: Monday, August 19, 2019 at 8:39 AM
> >> From: "Cristián Maureira-Fredes" <Cristian.Maureira-Fredes at qt.io>
> >> To: "development at qt-project.org" <development at qt-project.org>
> >> Subject: [Development] Technical vision for Qt for Python
> > ...
> >> It will be really nice to know what do you think,
> >> because at the moment we have been mostly community driven,
> >> and many aspects from the C++ expertise on this mailing list
> >> will help us improving Qt for Python.
> >> https://blog.qt.io/blog/2019/08/19/technical-vision-qt-python/
> Dr. Cristian Maureira-Fredes
> Software Engineer
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> D-12489 Berlin
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> Development mailing list
> Development at qt-project.org
More information about the Development