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

[Shaheed Haque]

Philipp,

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
have
brewed there will facilitate any ECM-based bindings. Note: the packaging
code depends very much on the evolving PR at
https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-experimental-version-of-a.
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 __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):
>
> *namespace-test-1/namespace_test/namespace_test_1_init.py*:
> FOO = 1
> *namespace-test-2/namespace_test/**namespace_test_2_init.py*:
> BAR= 1
> *namespace-test-{1,2}/namespace_test/**__init__.py*:
> 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 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
> 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: <http://mail.kde.org/pipermail/kde-bindings/attachments/20171105/e1e8f2c1/attachment.html>