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

M.-A. Lemburg mal at egenix.com
Tue Apr 14 17:02:39 CEST 2009

On 2009-04-07 19:46, P.J. Eby wrote:

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.extendpath() (in the stdlib since 2.3, btw) or pkgresources.declarenamespace() (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.)

The purpose of the PEP is to create a standard for namespace packages. That's orthogonal to trying to enhance or change some existing techniques.

I don't see the emphasis in the PEP on Linux distribution support and the remote possibility of them wanting to combine separate packages back into one package as good argument for adding yet another separate hierarchy of special files which Python scans during imports.

That said, note that most distributions actually take the other route: they try to split up larger packages into smaller ones, so the argument becomes even weaker.

It is much more important to standardize the approach than to try to extend some existing trickery and make them even more opaque than they already are by introducing yet another level of complexity.

My alternative approach builds on existing methods and fits nicely with the init.py approach Python has already been using for more than a decade now. It's transparent, easy to understand and provides enough functionality to build upon - much like the original init.py idea.

I've already laid out the arguments for and against it in my previous reply, so won't repeat them here.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Apr 14 2009)

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2009-03-19: Released mxODBC.Connect 1.0.1 http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

More information about the Python-Dev mailing list