> Note that there is no such thing as a "defining namespace package" --
> namespace package contents are symmetrical peers.

With the PEP, a "defining package" becomes possible - at most one
portion can define an __init__.py.

I know that the current mechanisms don't support it, and it might
not be useful in general, but now there is a clean way of doing it,
so I wouldn't exclude it. Distribution-wise, all distributions
relying on the defining package would need to require (or
install_require, or depend on) it.

> The above are also true for using only a '*' in .pkg files -- in that
> event there are no sys.path changes.  (Frankly, I'm doubtful that
> anybody is using extend_path and .pkg files to begin with, so I'd be
> fine with a proposal that instead used something like '.nsp' files that
> didn't even need to be opened and read -- which would let the directory
> scan stop at the first .nsp file found.

That would work for me as well. Nobody at PyCon could remember where
.pkg files came from.

> I believe the PEP does this as well, IIUC.

Correct.

>> * It's possible to have a defining package dir and add-one package
>> dirs.
>
> Also possible in the PEP, although the __init__.py must be in the first
> such directory on sys.path.

I should make it clear that this is not the case. I envision it to work
this way: import zope
- searches sys.path, until finding either a directory zope, or a file
  zope.{py,pyc,pyd,...}
- if it is a directory, it checks for .pkg files. If it finds any,
  it processes them, extending __path__.
- it *then* checks for __init__.py, taking the first hit anywhere
  on __path__ (just like any module import would)

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).
">

(original) (raw)



On Fri, Apr 3, 2009 at 13:15, "Martin v. Löwis" <martin@v.loewis.de> wrote:

> Note that there is no such thing as a "defining namespace package" --
> namespace package contents are symmetrical peers.

With the PEP, a "defining package" becomes possible - at most one
portion can define an \_\_init\_\_.py.

I know that the current mechanisms don't support it, and it might
not be useful in general, but now there is a clean way of doing it,
so I wouldn't exclude it. Distribution-wise, all distributions
relying on the defining package would need to require (or
install\_require, or depend on) it.

> The above are also true for using only a '\*' in .pkg files -- in that
> event there are no sys.path changes. (Frankly, I'm doubtful that
> anybody is using extend\_path and .pkg files to begin with, so I'd be
> fine with a proposal that instead used something like '.nsp' files that
> didn't even need to be opened and read -- which would let the directory
> scan stop at the first .nsp file found.

That would work for me as well. Nobody at PyCon could remember where
.pkg files came from.

> I believe the PEP does this as well, IIUC.

Correct.

>> \* It's possible to have a defining package dir and add-one package
>> dirs.
>
> Also possible in the PEP, although the \_\_init\_\_.py must be in the first
> such directory on sys.path.

I should make it clear that this is not the case. I envision it to work
this way: import zope
\- searches sys.path, until finding either a directory zope, or a file
zope.{py,pyc,pyd,...}
\- if it is a directory, it checks for .pkg files. If it finds any,
it processes them, extending \_\_path\_\_.
\- it \*then\* checks for \_\_init\_\_.py, taking the first hit anywhere
on \_\_path\_\_ (just like any module import would)

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).



-Brett



- if no .pkg was found, nor an __init__.py, it proceeds with the next

sys.path item (skipping the directory entirely)