<div dir="ltr"><div class="gmail_default"><font color="#000000">The documentation is pretty opaque or non-existent on other aspects of importlib use, too.  If I enable warnings, I see this (and many more like it).  I've read PEP 302 a couple times, read the code in importlib that detects the warning and searched down several rabbit holes, only to come up empty...</font></div><div class="gmail_default"><font color="#000000"><br></font></div><div class="gmail_default"><font color="#000000">T:\Python36\lib\importlib\_bootstrap.py:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__</font><br></div><div class="gmail_default"><font color="#000000"><br></font></div><div class="gmail_default"><font color="#000000">My thoughts when I see it: "Ok.  So what does that mean?  Is it bad?  It must be bad, otherwise I wouldn't get a warning.  How do I reconcile __spec__ and __package__?  Which one is missing and/or incorrect?"</font></div><div class="gmail_default"><font color="#000000"><br></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 16, 2018 at 9:36 AM, 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"><span class="">On 16 April 2018 at 17:22, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> If we're not covering explicit __path__ manipulation anywhere, we<br>
> should definitely mention that possibility.<br>
> <a href="https://docs.python.org/3/library/pkgutil.html#pkgutil.extend_path" rel="noreferrer" target="_blank">https://docs.python.org/3/<wbr>library/pkgutil.html#pkgutil.<wbr>extend_path</a><br>
> does talk about it, but only in the context of scanning sys.path for<br>
> matching names, not in the context of building a package from an<br>
> arbitrary set of directory names.<br>
<br>
</span>It's quite possible that we're not.<br>
<span class=""><br>
> I'm not sure where we could put an explanation of some of the broader<br>
> implications of that fact, though - while __path__ manipulation is<br>
> usually fairly safe, we're always a little hesitant about encouraging<br>
> too many dynamic modifications to the import system state, since it<br>
> can sometimes have odd side effects based on whether imports happen<br>
> before or after that state is adjusted..<br>
<br>
</span>One of the problems with PEP 302 was that there was no really good<br>
place in the documentation to put all the information that was present<br>
(certainly not in the version of the docs that was around when we<br>
wrote it). So a lot of the important details remained buried in PEP<br>
302. Since then, a lot of the details ended up in the docs, mostly in<br>
the importlib sections, but I don't recall ever seeing anything about<br>
__path__ (and particularly not the nice summary you gave, "packages<br>
<span class="">are ultimately just modules with a<br>
</span>__path__ attribute that works like sys.path".<br>
<span class="HOEnZb"><font color="#888888"><br>
Paul<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</div></div></blockquote></div><br></div>