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-sh...@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 <srha...@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 <b...@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 >>> >> >>
