[Import-SIG] PEP 382 update
"Martin v. Löwis"
martin at v.loewis.de
Wed Oct 19 22:36:24 CEST 2011
[TL;DR: namespace packages are now indicated by directories ending in .pyp]
I just updated PEP 382, to reflect discussions here on the list and at
PyCon DE. As you may recall, it originally proposed to have .pth files
in a directory to indicate that it's a namespace package. Then the
extension got changed to .pyp, and the file was proposed to merely be
a marker file (raising the question what the file name should be).
Dinu Gherman has now proposed that just changing the directory name
itself should be sufficient, so I changed the PEP accordingly. This also
simplifies the impact on PEP 302 importers.
With PEP 382, a package P is indicated either by being a directory P
with an __init__.py, or by being a directory P.pyp. Each such directory
only defines a portion of the package; the parent path (or sys.path)
is scanned for all directories having the name P.pyp, and together they
form the __path__ attribute of the package. If a P/__init__.py is
available, it is executed at package import time; if only P.pyp
directories are there, the package starts out empty (except for
__name__, __path__, __doc__, etc).
In comparison with PEP 402, after my PyCon DE presentation, people
discussed that they prefer if Python packages require some kind of
explicit declaration - even though Java seems to have done well with
packages being just directories with the package name. In particular,
a Jython guy observed that they would likely have issues with an
approach where a directory P would already be part of a package P,
since they often have directories in Jython that have the name of
Python packages, but are not meant as such.
Since explicit declaration is apparently desired, this would bring
us to having a marker file - or just marking the directory itself.
Apple has a long tradition of doing so on OS X, and users would
right away guess that a .pyp directory is about Python, even if
they don't know exactly what it is.
This approach also supports one of the original motivations of
PEP 382, namely that Linux distributions can opt to install many
package portions (such as zope.*) into a single file system location.
With this PEP, this would all end up in zope.pyp (e.g.
zope.pyp/tal; or even zope.pyp/tal.pyp, since TAL doesn't use
the __init__.py feature).
Please let me know what you think.
Regards,
Martin
More information about the Import-SIG
mailing list