El dissabte, 13 de gener de 2018, a les 18:05:45 CET, Shaheed Haque va escriure: > Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and > also Qt5 (see below) showing signs of life. > Notes:
This is awesome, i'm really happy we're in a point that framework-by-framework is possible and that it all seems to be upstream so it's a "hopefully bigger group of people" maintaining it :) Keep it up! Cheers, Albert > > > 1. The packaging has advanced to the point where I think ECM-based > framework-by-framework bindings are a real possibility, with both Py2 and > Py3. AFAICS, this addresses the main feedback received to date. 2. With > reference to the remark about tracking dependencies between frameworks, > apologies for the delayed response as I somehow missed the email. I note > that the dependencies currently in CMake often seem incomplete. I'll bring > that to the community separately. > 3. There is one issue still open upstream ( > > https://bitbucket.org/wlav/cppyy/issues/16/pragma-link-defined_in-seems-to-> > select). However, I don't consider this to be a showstopper...we might even > be able to live with it as is. > 4. For me, the jury is still out on PyQt versus a new set of cppyy-based > Qt bindings. Clearly PyQt is solid and mature, but the limitations really > concern me (if anybody wants to know more, I'm happy to discuss, but let's > do that in another thread please). Now, given that there are examples in > the wild of interoperating cppyy/cling/ROOT with PyQt, I'm going to > sidestep this question but am playing with a cppyy-based approach. At this > point, all of Qt has basic cppyy-based bindings, and the next step is to > tackle things like finding a way to express the object > ownership/destruction rules in a more-or-less systematic way. > 5. On the P2/P3 question, I'm presently still committed to both P2 and > P3. I *have* had a couple of minor occasions where P3-only might have > been nice *for my code*, but if I do find an issue that tips the balance, > or I find some serious benefit *for the bindings*, I'll drop P2. One > possible such benefit would be if I can see a sane way to address PEP484 > type hints. > > To get here, I had to build a subset of the tooling I previously had > developed for the SIP-based approach. The big difference is the absence of > any need to support customisation of the generated bindings. I am hopeful > that in the worst case, there might be some minimal customisation (known as > Pythonisations in cppyy parlance) such as for #4 above, but nothing like > the scale needed for SIP. > > The core tooling is not specific to KF5 or KDE or Qt5, and is developed in > upstream cppyy over on bitbucket.org. The core tooling is built around > CMake, notably for the generation phase and the C++ library build. > > The PoC extends the core tooling with Pythonic packaging and installation > using pip/wheels, also from CMake. As before I would look for help to get > an ECM equivalent, possibly based on the same approach but perhaps > including CI and distribution via PyPi. > > Finally, now would be a good time for anybody else who wants to get > involved to step up, especially as a new job limits my free time. > > Thanks, Shaheed > > P.S. Not to stoke the the P2/P3 wars unnecessarily, but while I know that > upstream Clang just added P3 support in the clang 5.0 release, current > Ubuntu only packages it for 2.7.14. So I won't be moving yet... > > On 5 November 2017 at 13:23, Boudewijn Rempt <b...@valdyas.org> wrote: > > On Sat, 4 Nov 2017, Chris Burel wrote: > > > I think this is a remarkably short sighted statement. It assumes that > > > > people that would use these bindings have no existing Python codebase at > > all, and can afford to start a brand new project. The reality is much > > different. > > > > > Let's take a specific example. I have 6 years experience writing Python > > > > for the visual effects industry. We have a 10 year old Python 2 codebase. > > We also use an application from Autodesk called Maya. It has been a Qt 4 > > application with Python 2 embedded since 2012. In 2016 they jumped to qt 5 > > and pyside2. Now Autodesk knows that companies have built large codebase > > around their product that requires Python 2. What would've happened if > > pyside2 did not support Python 2.7? They'd be stuck either forcing all > > their customers to move to Python 3 and risk people not wanting the new > > version of the software, or they'd be prevented from moving to Qt 5. > > > > > > You will have to switch to Python 3 by 2019, since that's what the VFX > > Reference Platform says. If you haven't started on the migration yet, > > you're very late. And the VFX Refernece Platform is basically Autodesk > > telling the rest of the industry what to use, including their weird > > patchset for Qt... > > > > > So no, Python 2 is not dead. Not by a long shot. > > > > For VFX, it will be dead in 2019. See http://www.vfxplatform.com/ > > > > > > -- > > Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org