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

[Shaheed Haque]

Hi Luca,

On 15 January 2018 at 08:24, Luca Beltrame <lbeltrame at kde.org> wrote:

> Il giorno Sat, 13 Jan 2018 18:05:45 +0000
> Shaheed Haque <srhaque at theiet.org> ha scritto:
>
> Hello Shaheed,
>
> >    1. The packaging has advanced to the point where I think ECM-based
> >    framework-by-framework bindings are a real possibility, with both
>
> That's absolutely fantastic. Thanks for the continued effort!
>

It is a relief to get to this point after what, about 2 years? Also, a lot
of credit has to go to the support of upstream (Wim, but also not
forgettting Phil on the the SIP side of things). Still, it is not quite
time to put out the bunting...

>
> >    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
>
> How do the bindings work? I suppose you'll need cppyy-based Qt to run
> your bindings, correct?
>

Technically, there seem to be example in the wild of people (at CERN and
possibly elsewhere?) creating applications with ROOT (the immediate
precursor of cppyy) and PyQt. And since everything is, at one level, just
Python, I don't see any bar to using PyQT. However, recall that I only went
down the cppyy route after pouring a LOT of effort into the SIP route, and
then concluding both the customisation effort and the limitations were too
great for my liking. Basically, I expect it would take ongoing large-scale
investment from somebody like me to keep the bindings going.

So, given the current cppyy Qt bindings required NO customisation effort
(but see below) and should free us of the limitations of the SIP-generated
approach, I'm putting my effort into the cppyy-based approach.

> like finding a way to express the object ownership/destruction rules
>
> How are you dealing with Python's GC? A major point (and PITA) when
> developing with PyQt and PyKDE4 was that a single slip in tracking
> objects meant the C++ object would get GC'd under your feet,
> causing crashes. This was particularly bad with the Plasma bindings
> because they would crash the whole desktop.
>

As you will understand, there is no magic bullet for this. Both SIP and
cppyy need to be told how to handle this. With SIP, part of the extensive
customisation framework I created allowed me to say things like:

-    for all constructors that match a set of regexps, and which have one
argument called "parent" of type "QWidget *", declare that Python does not
own the object

There is a similar capability in cppyy, and I just have to create a way to
pass that hint.


> > benefit *for the bindings*, I'll drop P2. One possible such benefit
>
> I don't mind either approach: FYI though, most major distros are
> phasing out Py2-as-default (Ubuntu, Arch, and openSUSE are the ones I'm
> aware of).
>
> > minimal customisation (known as Pythonisations in cppyy parlance)
> > such as for #4 above, but nothing like the scale needed for SIP.
>
> That would be great. It was one of the major issues when keeping PyKDE4
> up to date.
>

Precisely. In marked contrast to SIP, I am hopeful that this ownership
thingy may in fact be the ONLY customisation needed (though I/we need to
think about Qt meta object stuff like signals/slots too).


> > look for help to get an ECM equivalent, possibly based on the same
> > approach but perhaps including CI and distribution via PyPi.
>
> Can you link the repository with the tools?
>

Not sure what you mean. It is all on PyPI (and bitbucket):
https://pypi.python.org/pypi?%3Aaction=search&term=cppyy&submit=search.

Let me know if I missed your point.

Thanks, Shaheed


> --
> Luca Beltrame, Ph.D.
> Translational Genomics Unit, Department of Oncology
> IRCCS Istituto di Ricerche Farmacologiche "Mario Negri"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20180116/b09a5fb7/attachment.htm>