Python bindings using cppyy (was: An update on Python bindings)
Philipp A.
flying-sheep at web.de
Mon Nov 5 14:01:19 GMT 2018
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 theiet.org> 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 (
> 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-core-devel/attachments/20181105/b0bc7544/attachment.htm>
More information about the kde-core-devel
mailing list