[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bindings
Subject: Re: Python bindings using cppyy (was: An update on Python bindings)
From: Dominik Haumann <dhaumann () kde ! org>
Date: 2018-11-05 21:54:40
Message-ID: CALi_srCcvOU+-eSUKie90N__+NbB9gaETDO-oBwbh4qZ1Tb-hg () mail ! gmail ! com
[Download RAW message or body]
... wasn't there also some python related work by Stefan? Or is that
unrelated?
Greetings
Dominik
Am Mo., 5. Nov. 2018, 16:20 hat Shaheed Haque <srhaque@theiet.org>
geschrieben:
> 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@web.de 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@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@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
>>>>
>>>
>>>
[Attachment #3 (text/html)]
<div dir="auto"><div>... wasn't there also some python related work by Stefan? Or \
is that unrelated?<div dir="auto"><br></div><div dir="auto">Greetings</div><div \
dir="auto">Dominik</div><br><br><div class="gmail_quote"><div dir="ltr">Am Mo., 5. \
Nov. 2018, 16:20 hat Shaheed Haque <<a \
href="mailto:srhaque@theiet.org">srhaque@theiet.org</a>> \
geschrieben:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I'm afraid \
that there has been no progress as I am buried in "startup" mode. I'm \
not sure when that might change.<br><br><div class="gmail_quote"><div dir="ltr">On \
Mon, 5 Nov 2018, 14:02 Philipp A. <<a href="mailto:flying-sheep@web.de" \
target="_blank" rel="noreferrer">flying-sheep@web.de</a> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div>Hi Shaheed!</div><div><br></div><div>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!<br></div><div><br></div><div>I'd really like to \
revive my IPython console in Kate :D</div><div><br></div><div>Best, \
Philipp<br></div><div><br><div class="gmail_quote"><div dir="ltr">Shaheed Haque \
<<a href="mailto:srhaque@theiet.org" rel="noreferrer noreferrer" \
target="_blank">srhaque@theiet.org</a>> schrieb am Sa., 13. Jan. 2018 um 19:06 \
Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="auto"><div \
dir="ltr"><div><div>Thanks to some upstream fixes, I have the cppyy-based bindings \
for KF5 and also Qt5 (see below) showing signs of life. \
Notes:<br><br></div><ol><li>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.</li><li>With \
reference to the remark about tracking dependencies between frameworks, <span \
style="font-family:sans-serif">apologies for the delayed response as I somehow missed \
the email. I</span> note that the dependencies currently in CMake often seem \
incomplete. I'll bring that to the community separately.</li><li>There is one \
issue still open upstream (<a \
href="https://bitbucket.org/wlav/cppyy/issues/16/pragma-link-defined_in-seems-to-select" \
rel="noreferrer noreferrer" \
target="_blank">https://bitbucket.org/wlav/cppyy/issues/16/pragma-link-defined_in-seems-to-select</a>). \
However, I don't consider this to be a showstopper...we might even be able to \
live with it as is.</li><li>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.</li><li>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.</li></ol></div><div><div>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.<br></div><div><br></div><div>The core tooling is not specific to KF5 or KDE or \
Qt5, and is developed in upstream cppyy over on <a href="http://bitbucket.org" \
rel="noreferrer noreferrer" target="_blank">bitbucket.org</a>. The core tooling is \
built around CMake, notably for the generation phase and the C++ library \
build.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks, \
Shaheed<br></div><div><br></div><div>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...<br></div></div></div></div></div><div dir="ltr"><div dir="auto"><div \
dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 5 November 2017 at \
13:23, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org" \
rel="noreferrer noreferrer" target="_blank">boud@valdyas.org</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Sat, 4 Nov \
2017, Chris Burel wrote:<br> <br>
> 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.<br> ><br>
> 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.<br> \
><br> <br>
</span>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...<br> <span><br>
> So no, Python 2 is not dead. Not by a long shot.<br>
<br>
</span>For VFX, it will be dead in 2019. See <a href="http://www.vfxplatform.com/" \
rel="noreferrer noreferrer noreferrer" \
target="_blank">http://www.vfxplatform.com/</a><br> <span \
class="m_-1077599204917565001m_8222115862613284428m_1361868292272180300gmail-m_3618856278126829961m_6971320892976200561HOEnZb"><font \
color="#888888"><br> <br>
--<br>
Boudewijn Rempt | <a href="http://www.krita.org" rel="noreferrer noreferrer \
noreferrer" target="_blank">http://www.krita.org</a>, <a \
href="http://www.valdyas.org" rel="noreferrer noreferrer noreferrer" \
target="_blank">http://www.valdyas.org</a><br> \
</font></span></blockquote></div><br></div></div></div></div></blockquote></div></div></div>
</blockquote></div></div></div>
</blockquote></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic