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

[Philipp A.]

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

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-frameworks-devel/attachments/20171105/d6b6166a/attachment-0001.html>