<div class="gmail_quote">On Wed, Nov 16, 2011 at 1:29 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">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;">
So, without a clear answer to the question of "from module X, inside<br>
package (or package portion) Y, find the nearest parent directory that<br>
should be placed on sys.path" in a PEP 402 based world, I'm switching<br>
to supporting PEP 382 as my preferred approach to namespace packages.<br>
In this case, I think "explicit is better than implicit" means, "given<br>
only a filesystem hierarchy, you should be able to figure out the<br>
Python package hierarchy it contains". Only explicit markers (either<br>
files or extensions) let you do that - with PEP 402, the filesystem<br>
doesn't contain enough information to figure it out, you need to also<br>
know the contents of sys.path.<br></blockquote><div><br></div><div>After spending an hour or so reading through PEP 395 and trying to grok what it's doing, I actually come to the opposite conclusion: that PEP 395 is violating the ZofP by both guessing, and not encouraging One Obvious Way of invoking scripts-as-modules.</div>
<div><br></div><div>For example, if somebody adds an __init__.py to their project directory, suddenly scripts that worked before will behave differently under PEP 395, creating a strange bit of "spooky action at a distance". (And yes, people add __init__.py files to their projects in odd places -- being setuptools maintainer, you get to see a LOT of weird looking project layouts.)</div>
<div><br></div><div>While I think the __qname__ idea is fine, and it'd be good to have a way to avoid aliasing main (suggestion for how included below), I think that relative imports failing from inside a main module should offer an error message suggesting you use "-m" if you're running a script that's within a package, since that's the One Obvious Way of running a script that's also a module. (Albeit not obvious unless you're Dutch. ;-) )</div>
<div><br></div><div>For the import aliasing case, AFAICT it's only about cases where __name__ == '__main__', no? Why not just save the file/importer used for __main__, and then have the import machinery check whether a module being imported is about to alias __main__? For that, you don't need to know in *advance* what the qualified name of __main__ is - you just spot it the first time somebody re-imports it.</div>
<div><br></div><div>I think removing qname-quessing from PEP 395 (and replacing it with instructive/google-able error messages) would be an unqualified improvement, independent of what happens to PEPs 382 and 402.</div><div>
<br></div></div>