<div dir="ltr">Philipp,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On 5 November 2017 at 14:48, Philipp A. <span dir="ltr"><<a href="mailto:flying-sheep@web.de" target="_blank">flying-sheep@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hi Shaheed, Chris,<br><br><div class="gmail_quote"><div dir="ltr">Shaheed Haque <<a href="mailto:srhaque@theiet.org" target="_blank">srhaque@theiet.org</a>> schrieb am Sa., 4. Nov. 2017 um 18:35 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">FWIW, I already tried that (types.ModuleType is itself a perfectly subclassable class!) […]<span class="gmail-"><br><br>Now, none of that may be a limiting factor in the plan you seem to be<br>discussing, but it was part of what made me think "here be dragons"...</span></blockquote><div><br></div><div>For me that sounds like a perfectly acceptable clearly-defined instruction:</div><div><ul><li>If you can, don’t use a __init__.py for namespace packages (because it’s simple).<br></li><li>If you need an __init__.py, only use one or use identical ones.</li></ul></div><div>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.<br></div><div><br></div><div>I created an example here: <a href="https://github.com/flying-sheep/namespace-test" target="_blank">https://github.com/<wbr>flying-sheep/namespace-test</a></div></div></div></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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 <br><div>brewed there will facilitate any ECM-based bindings. Note: the packaging code depends very much on the evolving PR at <a href="https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-experimental-version-of-a">https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-experimental-version-of-a</a>. Neither branch is ready to merge or formally review.<br></div></div><div><br></div><div>I plan to continue to push forward on the remaining functional TODOs.</div><div><br></div><div>Thanks, Shaheed<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div>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.</div><div><br></div><div>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):</div><div><br></div><div><b>namespace-test-1/namespace_<wbr>test/namespace_test_1_init.py</b>:<br></div><div>FOO = 1</div><div><b>namespace-test-2/namespace_<wbr>test/</b><b>namespace_test_2_init.py</b>:</div><div>BAR= 1</div><div><b>namespace-test-{1,2}/<wbr>namespace_test/</b><b>__init__.py</b>:</div><div><div>from pkgutil import extend_path</div><div>__path__ = extend_path(__path__, __name__)</div></div><div>try:<br></div><div> from .namespace_test_1_init import *</div><div>except ImportError:</div><div> pass</div><div>try:</div><div> from .namespace_test_2_init import *</div><div>except ImportError:</div><div> pass</div></div></div><div dir="ltr"><br></div><div dir="ltr">Chris Burel <<a href="mailto:chrisburel@gmail.com" target="_blank">chrisburel@gmail.com</a>> schrieb am So., 5. Nov. 2017 um 02:49 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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. […]</blockquote><div><br></div><div>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.</div><div><br></div><div>Therefore the only thing Python 2 KF5 bindings would accomplish is to make people think that starting a <b>new</b> Python 2 project in 2018 was still a good idea. Which it isn’t.</div></div></div>
</blockquote></div><br></div></div></div>