[Python-Dev] PEP 382 specification and implementation complete
ncoghlan at gmail.com
Sun Nov 6 13:29:56 CET 2011
On Sun, Nov 6, 2011 at 6:10 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> I had announced this to import-sig already; now python-dev.
> I have now written an implementation of PEP 382, and fixed some details
> of the PEP in the process. The implementation is available at
> With this PEP, a Python package P can consist of either a P/__init__.py
> directory and module, or multiple P.pyp directories, or both. Using a
> directory suffix resulted from the following requirements/observations:
> - people apparently prefer an approach where a directory has to be
> declared as a Python package (several people commented this after
> my PyConDE talk, expressing dislike of how Java packages are
> "unflagged" directories)
> - people also commented that any declaration should indicate that this
> is about Python, hence the choice of .pyp as the directory suffix.
> - in choosing between a file marker inside of the directory (e.g.
> zope-interfaces.pyp) and a directory suffix, the directory suffix
> wins for simplicity reasons. A file marker would have to have a
> name which wouldn't matter except that it needs to be unique - which
> is a confusing requirement that people likely would fail to meet.
I finally got around to doing the search Barry and I promised for the
previously raised objections to the directory suffix approach.
They were in the "Rejected Alternatives" section of PJE's proposed
redraft of PEP 382 (before he decided to create PEP 402 as a competing
* Another approach considered during revisions to this PEP was to
simply rename package directories to add a suffix like ``.ns``
or ``-ns``, to indicate their namespaced nature. This would effect
a small performance improvement for the initial import of a
namespace package, avoid the need to create empty ``*.ns`` files,
and even make it clearer that the directory involved is a namespace
The downsides, however, are also plentiful. If a package starts
its life as a normal package, it must be renamed when it becomes
a namespace, with the implied consequences for revision control
Further, there is an immense body of existing code (including the
distutils and many other packaging tools) that expect a package
directory's name to be the same as the package name. And porting
existing Python 2.x namespace packages to Python 3 would require
widespread directory renaming as well.
In short, this approach would require a vastly larger number of
changes to both the standard library and third-party code, for
a tiny potential performance improvement and a small increase in
clarity. It was therefore rejected on "practicality vs. purity"
I think this was based on the assumption that *existing* namespace
package approaches would break under the new scheme. Since that is not
the case, I suspect those previous objections were overstated (and all
packaging related code manages to cope well enough with modules where
the file name doesn't match the package name)
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev