<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">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!) […]<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"...</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">https://github.com/flying-sheep/namespace-test</a><br></div><div><br></div><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_test/namespace_test_1_init.py</b>:<br></div><div>FOO = 1</div><div><b>namespace-test-2/namespace_test/</b><b>namespace_test_2_init.py</b>:</div><div>BAR= 1</div><div><b>namespace-test-{1,2}/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">chrisburel@gmail.com</a>> schrieb am So., 5. Nov. 2017 um 02:49 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>