Python bindings using cppyy (was: An update on Python bindings)

[Shaheed Haque]

Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and
also Qt5 (see below) showing signs of life. Notes:


   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 <boud at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180113/1edf50c3/attachment.html>