<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>