Python bindings using cppyy (was: An update on Python bindings)

Shaheed Haque srhaque at
Sun Nov 5 21:30:32 GMT 2017


On 5 November 2017 at 14:48, Philipp A. <flying-sheep at> wrote:

> Hi Shaheed, Chris,
> Shaheed Haque <srhaque at> 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 for namespace packages (because
>    it’s simple).
>    - If you need an, only use one or use identical ones.
> Reasons for needing a include the need for toplevel
> constants/classes/functions, or supporting Python 2. The docs also say that
> you can mix omission and (identical) __init__.pys.
> I created an example here:

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.

Thanks, Shaheed

You can see that by using a 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):
> *namespace-test-1/namespace_test/*:
> FOO = 1
> *namespace-test-2/namespace_test/***:
> BAR= 1
> *namespace-test-{1,2}/namespace_test/***:
> from pkgutil import extend_path
> __path__ = extend_path(__path__, __name__)
> try:
>     from .namespace_test_1_init import *
> except ImportError:
>     pass
> try:
>     from .namespace_test_2_init import *
> except ImportError:
>     pass
> Chris Burel <chrisburel at> 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
> project.
> 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...
URL: <>

More information about the kde-core-devel mailing list