<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 March 2017 at 00:00, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As a theoretical example:<br>
<br>
foo 1.0 looks like this:<br>
<br>
    foo<br>
        __init__.py<br>
        bar.py<br>
<br>
foo 2.0 moves the functionality of foo/bar.py into baz.py<br>
<br>
    foo<br>
        __init__.py<br>
        baz.py<br>
<br>
Put both of these on sys.path, then you can successfully import<br>
foo.bar and foo.baz. Which is of course wrong. Furthermore, which<br>
version of foo/__init__.py gets imported depends on which version of<br>
foo is first on sys.path, so one of bar and baz will be using the<br>
wrong foo.<br></blockquote><div><br></div></div>Unless the __init__.py has its own __path__ extension code, whichever version of "foo" is first on sys.path will "win", and you won't be able to import from the other one (so you'll be able to import "foo.bar" or "foo.baz", but not both). That's not an accident, it's behaviour that was deliberately kept for backwards compatibility reasons when PEP 420's native namespace package support was being designed.<br><br></div><div class="gmail_extra">You only get the "you can import both of them" behaviour if "foo" is a namespace package, at which point "foo" itself doesn't really have a version any more.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>