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
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
hmark. 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] Techn
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
__
> > 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
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
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
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 Java
