<p><br>
On Mar 14, 2012 6:25 AM, "Eric Snow" <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>> wrote:<br>
><br>
> Here's one idea to address the PEP 395 concern.<br>
><br>
> Traverse up the directory tree until you hit one of the following three markers:<br>
><br>
> * there is no __init__.py in the current directory (in the case where<br>
> there was one adjacent to the original module)<br>
> * current directory is on sys.path<br>
> * setup.py is in the current directory<br>
><br>
> All these indicate that you have left the package. If you make it to<br>
> the FS root, the module would not be considered to exist in a package.<br>
><br>
> The third option is the new idea. As a bonus, using setup.py as a<br>
> marker would also nudge people toward packaging.<br>
><br>
> -eric</p>
<p>Alas, that doesn't work - to avoid slowing down normal startup too much, there needs to be a *fast* check that tells the interpreter immediately whether or not it is inside a package and needs to search the filesystem for the parent of the package directory. That's only possible when each package directory has an explicit marker.</p>
<p>Instead, I'll have to put the search in importlib so the import error message can tell the user which directory to switch to and what "python -m" command to use to run their module. I do like the idea of using <a href="http://setup.py/cfg">setup.py/cfg</a> as an extra marker, though. </p>
<p>I'll be moving house over the next few days and only have mobile internet at home for a while after that, so I'll probably revise PEP 395 some time after the next 3.3 alpha.</p>
<p>Cheers,<br>
Nick.</p>
<p>--<br>
Sent from my phone, thus the relative brevity :) </p>