<br><br><div class="gmail_quote">On Fri, May 11, 2012 at 8:14 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>PJE's proposal that self-contained package loaders *also* report their prospective __path__ entries in the second half of the tuple sounds reasonable to me. It provides a way to cleanly distinguish all 4 significant cases (standalone module, regular package, package portion, not found).</p>
<p>The standard import system will treat the first two cases the same way, but making the distinction official means custom import systems can decide to do something different.</p></blockquote><div><br></div><div>If we are going as far as to have finders return the value of __path__, should we add an equivalent extension to the loader API to get the sequence back? I have always found it extremely regrettable that is_package() was defined to return a boolean instead of the list for __path__. Otherwise I would at least want to change the __init__ signature for the various loaders that FileFinder uses to take this new path argument so it doesn't need to be recalculated and then expose it somehow as an attribute (although right now FileLoader already sets a 'path' attribute; might need to rename that filepath/file_path).</div>
</div>