Python bindings using cppyy (was: An update on Python bindings)
srhaque at theiet.org
Sun Nov 5 21:30:32 GMT 2017
On 5 November 2017 at 14:48, Philipp A. <flying-sheep at web.de> wrote:
> Hi Shaheed, Chris,
> Shaheed Haque <srhaque at theiet.org> schrieb am Sa., 4. Nov. 2017 um
> 18:35 Uhr:
>> FWIW, I already tried that (types.ModuleType is itself a perfectly
>> subclassable class!) […]
>> Now, none of that may be a limiting factor in the plan you seem to be
>> discussing, but it was part of what made me think "here be dragons"...
> For me that sounds like a perfectly acceptable clearly-defined instruction:
> - If you can, don’t use a __init__.py for namespace packages (because
> it’s simple).
> - If you need an __init__.py, only use one or use identical ones.
> Reasons for needing a __init__.py include the need for toplevel
> constants/classes/functions, or supporting Python 2. The docs also say that
> you can mix __init__.py omission and (identical) __init__.pys.
> I created an example here: https://github.com/flying-sheep/namespace-test
As I said, I know how this works, and am using it. As I also said, I'm
happy for others to pursue ECM-based bindings because I don't plan to.
My branch in pykde5.git is now at the point where the packaging now works
with wheels. With any luck, the combination of CMake and pip/setuptools I
brewed there will facilitate any ECM-based bindings. Note: the packaging
code depends very much on the evolving PR at
Neither branch is ready to merge or formally review.
I plan to continue to push forward on the remaining functional TODOs.
You can see that by using a __init__.py in exactly one of the merged
> packages, you can define toplevel constants/classes/functions like BASE in
> the example.
> If we need, we can also define toplevel constants and so on in multiple
> distributions, like this (this specific version requires all distributions
> to know about all others, but that’s automatable):
> FOO = 1
> BAR= 1
> from pkgutil import extend_path
> __path__ = extend_path(__path__, __name__)
> from .namespace_test_1_init import *
> except ImportError:
> from .namespace_test_2_init import *
> except ImportError:
> Chris Burel <chrisburel at gmail.com> schrieb am So., 5. Nov. 2017 um
> 02:49 Uhr:
>> 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. […]
> No, because you’re missing something here: There’s no KF5 bindings. So
> every project that’ll use Shaheed’s new cool KF5 bindings will be a new
> Therefore the only thing Python 2 KF5 bindings would accomplish is to make
> people think that starting a *new* Python 2 project in 2018 was still a
> good idea. Which it isn’t.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kde-core-devel