[Python-Dev] PEP 382: Namespace Packages (original) (raw)

P.J. Eby pje at telecommunity.com
Tue Apr 7 19:46:21 CEST 2009

At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote:

On 2009-04-07 16:05, P.J. Eby wrote: > At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote: >> >> Wouldn't it be better to stick with a simpler approach and look for >> >> "pkg.py" files to detect namespace packages using that O(1) >> check ? >> > >> > Again - this wouldn't be O(1). More importantly, it breaks system >> > packages, which now again have to deal with the conflicting file names >> > if they want to install all portions into a single location. >> >> True, but since that means changing the package infrastructure, I think >> it's fair to ask distributors who want to use that approach to also take >> care of looking into the pkg.py files and merging them if >> necessary. >> >> Most of the time the pkg.py files will be empty, so that's not >> really much to ask for. > > This means your proposal actually doesn't add any benefit over the > status quo, where you can have an init.py that does nothing but > declare the package a namespace. We already have that now, and it > doesn't need a new filename. Why would we expect OS vendors to start > supporting it, just because we name it pkg.py instead of init.py?

I lost you there. Since when do we support namespace packages in core Python without the need to add some form of magic support code to init.py ? My suggestion basically builds on the same idea as Martin's PEP, but uses a single pkg.py file as opposed to some non-Python file yaddayadda.pkg.

Right... which completely obliterates the primary benefit of the original proposal compared to the status quo. That is, that the PEP 382 way is more compatible with system packaging tools.

Without that benefit, there's zero gain in your proposal over having init.py files just call pkgutil.extend_path() (in the stdlib since 2.3, btw) or pkg_resources.declare_namespace() (similar functionality, but with zipfile support and some other niceties).

IOW, your proposal doesn't actually improve the status quo in any way that I am able to determine, except that it calls for loading all the pkg.py modules, rather than just the first one. (And the setuptools implementation of namespace packages actually does load multiple init.py's, so that's still no change over the status quo for setuptools-using packages.)

More information about the Python-Dev mailing list