Re: [Development] Technical vision for Qt for Python
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. 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. I also have to point out that there was a statement made by Lars to make QML [more] strongly typed. I had expected that from the beginning, that Python would be the scripting language of QML, not Javascript[0], just for this reason. Instead, V4 was developed... I would probably execute Qt6 QML as Python code, not Javascript. I've repeatedly called for QML to be a web framework, and I've routinely had that idea shot down. So why involve a web language at all[1][2]? Coincidentally, you will also get that AI stuff Lars also talked about, for free (on the Python side anyway) 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?) 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. Footnotes: 0. C++ devs went with loosely-typed Javascript? Really shocked me. 1. Since Qt lagged many years in getting an ECMA Script 7 implementation, chasing this evolving standard might not be the best. 2. Why maintain V4? > Sent: Monday, August 19, 2019 at 8:39 AM > From: "Cristián Maureira-Fredes" > To: "development@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/ > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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: https://wiki.qt.io/Qt_for_Python_Missing_Bindings 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 also have to point out that there was a statement made by Lars to make QML > [more] strongly typed. I had expected that from the beginning, that Python > would be the scripting language of QML, not Javascript[0], just for this > reason. Instead, V4 was developed... I would probably execute Qt6 QML as > Python code, not Javascript. I've repeatedly called for QML to be a web > framework, and I've routinely had that idea shot down. So why involve a web > language at all[1][2]? Coincidentally, you will also get that AI stuff Lars > also talked about, for free (on the Python side anyway) 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, Cheers > (snip) > > > >> Sent: Monday, August 19, 2019 at 8:39 AM >> From: "Cristián Maureira-Fredes" >> To: "development@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Technical vision for Qt for Python
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" > To: "development@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: > https://wiki.qt.io/Qt_for_Python_Missing_Bindings > > 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 also have to point out that there was a statement made by Lars to make > > QML [more] strongly typed. I had expected that from the beginning, that > > Python would be the scripting language of QML, not Javascript[0], just for > > this reason. Instead, V4 was developed... I would probably execute Qt6 QML > > as Python code, not Javascript. I've repeatedly called for QML to be a web > > framework, and I've routinely had that idea shot down. So why involve a web > > language at all[1][2]? Coincidentally, you will also get that AI stuff Lars > > also talked about, for free (on the Python side anyway) > > 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 conce
Re: [Development] Technical vision for Qt for Python
On Monday, 19 August 2019 08:55:45 PDT Jason H wrote: > Can Qt set a "no private destructor!" rule? No. Private destructors have a purpose. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Technical vision for Qt for Python
> > Can Qt set a "no private destructor!" rule? > > No. > > Private destructors have a purpose. Would a workable re-wording be "always provide a public means of destruction"? To be clear, I am not sure what the actual issue is, why it's private, or why shiboken can't handle it. In the immediate case PyQt provides the class so there seems to be some way around the issue... ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Technical vision for Qt for Python
Dear all, I am using PyQt since 10 years now and my points are: - It is true that missing bindings is a serious issue to use PySide actually. - I noticed PyQt has simpler wrapper code, but I don't investigated more. - I would dream to have Python instead of JS, but we know how to implement a good JS virtual machine, for Python who really knows ??? - I experimented complex issues and I don't know how to debug them : we need a good debugging tool to figure out what happen in threads signal/slot ... - A good tutorial : how to wrap your custom C++ classes ( maybe there is one ??? ) - I think that something like a white paper " how to make a reactive Python/Qt application " would help people to understand GIL issue and how to deal with it. Because we can make serious applications using Python/Qt and competitive with Electron. - support async and pypy - A referential of applications that just works ( I could provide https://github.com/FabriceSalvaire/book-browser ) Cheers Le 19/08/2019 à 14:39, Cristián Maureira-Fredes a écrit : Hello, After the general discussion of the vision for Qt6, we wanted to say a few things regarding Qt for Python. Even though we are talking about a Python module, the whole development is C and C++ related, and due to Python's popularity, we have been getting a lot of attention on Shiboken, the binding generator that we use to expose our beloved C++ framework to Python. That's why I felt motivated to write to the main qt mailing list. A couple of people here has provided us with really nice feedback regarding the module, and even related to the integration with QtCreator. We are really thankful for that. Since the beginning of the project we have seen it as a complementary project, and never as a competition to the long-standing performant C++ counterpart, but most importantly as a really nice way to extend the Qt project community with a whole new set of users. As you will read on the blog post, there are a couple of aspects from the C++ point of view that are really useful, like fast prototyping, exposing existing C++ projects to Python, or even extend Qt/C++ application with 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/ Cheers ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Technical vision for Qt for Python
On Monday, 19 August 2019 12:34:23 PDT Jason H wrote: > > > Can Qt set a "no private destructor!" rule? > > > > No. > > > > Private destructors have a purpose. > > Would a workable re-wording be "always provide a public means of > destruction"? No, since the purpose is to prevent you from doing that. That's usually a singleton, though not always. > To be clear, I am not sure what the actual issue is, why it's private, or > why shiboken can't handle it. In the immediate case PyQt provides the class > so there seems to be some way around the issue... From knowledge of past code generators, they try to derive from every class, so any class that is final or has only private constructors or has a private destructor will fail. It needs a different strategy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Technical vision for Qt for Python
Jason H wrote: > I also have to point out that there was a statement made by Lars to make > QML [more] strongly typed. I had expected that from the beginning, that > Python would be the scripting language of QML, not Javascript[0], I don't see how Python is inherently more strongly typed than JavaScript. Python variables are untyped, method calls are duck-typed and hence work with any type that happens to implement the called method. The variable contents at a specific point in time are typed at runtime, but that is not strong typing. Any type mismatches are only caught when you actually run the code, just as in JavaScript. And the type of a variable can also change each time it is reassigned, just as in JavaScript. Python now has the typing module which allows you to set type hints, but they are not directly part of the language and in particular not enforced by default. (You have to actually run some static type checker explicitly to validate them.) The module is also provisional, which means that the API is subject to change. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
