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

Dominik Haumann dhaumann at
Mon Nov 5 21:54:40 GMT 2018

... wasn't there also some python related work by Stefan? Or is that


Am Mo., 5. Nov. 2018, 16:20 hat Shaheed Haque <srhaque at>

> I'm afraid that there has been no progress as I am buried in "startup"
> mode. I'm not sure when that might change.
> On Mon, 5 Nov 2018, 14:02 Philipp A. <flying-sheep at wrote:
>> Hi Shaheed!
>> The year is nearing its end, and I wonder if there has been any progress
>> and/or if you people need help with the bindings!
>> I’d really like to revive my IPython console in Kate :D
>> Best, Philipp
>> Shaheed Haque <srhaque at> schrieb am Sa., 13. Jan. 2018 um
>> 19:06 Uhr:
>>> 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 (
>>>    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 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> 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
>>>> --
>>>> Boudewijn Rempt |,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the KWrite-Devel mailing list