Philipp, On 5 November 2017 at 14:48, Philipp A. <flying-sh...@web.de> wrote:
> Hi Shaheed, Chris, > > Shaheed Haque <srha...@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 <chrisbu...@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. >