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

David Cournapeau cournape at gmail.com
Tue Apr 7 17:29:02 CEST 2009

On Tue, Apr 7, 2009 at 11:58 PM, M.-A. Lemburg <mal at egenix.com> wrote:

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 ?

I think P. Eby refers to the problem that most packaging systems don't like several packages to have the same file - be it empty or not. That's my main personal grip against namespace packages, and from this POV, I think it is fair to say the proposal does not solve anything. Not that I have a solution, of course :)

cheers,

David

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. Here's a copy of the proposal, with some additional discussion bullets added: """ Alternative Approach: --------------------- 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 ? This would also avoid any issues you'd otherwise run into if you want to maintain this scheme in an importer that doesn't have access to a list of files in a package directory, but is well capable for the checking the existence of a file. Mechanism: ---------- If the import mechanism finds a matching namespace package (a directory with a pkg.py file), it then goes into namespace package scan mode and scans the complete sys.path for more occurrences of the same namespace package. The import loads all pkg.py files of matching namespace packages having the same package name during the search. One of the namespace packages, the defining namespace package, will have to include a init.py file. After having scanned all matching namespace packages and loading the pkg.py files in the order of the search, the import mechanism then sets the packages .path attribute to include all namespace package directories found on sys.path and finally executes the init.py file. (Please let me know if the above is not clear, I will then try to follow up on it.) Discussion: ----------- The above mechanism allows the same kind of flexibility we already have with the existing normal init.py mechanism. * It doesn't add yet another .pth-style sys.path extension (which are difficult to manage in installations). * It always uses the same naive sys.path search strategy. The strategy is not determined by some file contents. * The search is only done once - on the first import of the package. * It's possible to have a defining package dir and add-one package dirs. * The search does not depend on the order of directories in sys.path. There's no requirement for the defining package to appear first on sys.path. * Namespace packages are easy to recognize by testing for a single resource. * There's no conflict with existing files using the .pkg extension such as Mac OS X installer files or Solaris packages. * Namespace pkg.py modules can provide extra meta-information, logging, etc. to simplify debugging namespace package setups. * It's possible to freeze such setups, to put them into ZIP files, or only have parts of it in a ZIP file and the other parts in the file-system. * There's no need for a package directory scan, allowing the mechanism to also work with resources that do not permit to (easily and efficiently) scan the contents of a package "directory", e.g. frozen packages or imports from web resources. Caveats: * Changes to sys.path will not result in an automatic rescan for additional namespace packages, if the package was already loaded. However, we could have a function to make such a rescan explicit. """ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source  (#1, Apr 07 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/

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/cournape%40gmail.com

More information about the Python-Dev mailing list