<br><br><div class="gmail_quote">On Fri, Apr 3, 2009 at 13:15, "Martin v. Löwis" <span dir="ltr"><<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">> Note that there is no such thing as a "defining namespace package" --<br>
> namespace package contents are symmetrical peers.<br>
<br>
</div>With the PEP, a "defining package" becomes possible - at most one<br>
portion can define an __init__.py.<br>
<br>
I know that the current mechanisms don't support it, and it might<br>
not be useful in general, but now there is a clean way of doing it,<br>
so I wouldn't exclude it. Distribution-wise, all distributions<br>
relying on the defining package would need to require (or<br>
install_require, or depend on) it.<br>
<div class="im"><br>
> The above are also true for using only a '*' in .pkg files -- in that<br>
> event there are no sys.path changes. (Frankly, I'm doubtful that<br>
> anybody is using extend_path and .pkg files to begin with, so I'd be<br>
> fine with a proposal that instead used something like '.nsp' files that<br>
> didn't even need to be opened and read -- which would let the directory<br>
> scan stop at the first .nsp file found.<br>
<br>
</div>That would work for me as well. Nobody at PyCon could remember where<br>
.pkg files came from.<br>
<div class="im"><br>
> I believe the PEP does this as well, IIUC.<br>
<br>
</div>Correct.<br>
<div class="im"><br>
>> * It's possible to have a defining package dir and add-one package<br>
>> dirs.<br>
><br>
> Also possible in the PEP, although the __init__.py must be in the first<br>
> such directory on sys.path.<br>
<br>
</div>I should make it clear that this is not the case. I envision it to work<br>
this way: import zope<br>
- searches sys.path, until finding either a directory zope, or a file<br>
zope.{py,pyc,pyd,...}<br>
- if it is a directory, it checks for .pkg files. If it finds any,<br>
it processes them, extending __path__.<br>
- it *then* checks for __init__.py, taking the first hit anywhere<br>
on __path__ (just like any module import would)</blockquote><div><br>Just so people know how this __init__ search could be done such that __path__ is set from the .pkg is to treat it as a reload (assuming .pkg files can only be found off of sys.path).<br>
<br><br>-Brett<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
- if no .pkg was found, nor an __init__.py, it proceeds with the next<br>
sys.path item (skipping the directory entirely)<br></blockquote></div><br>