[Python-Dev] PEP 382 specification and implementation complete (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Sun Nov 6 13:29:56 CET 2011
- Previous message: [Python-Dev] PEP 382 specification and implementation complete
- Next message: [Python-Dev] PEP 382 specification and implementation complete
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 http://hg.python.org/features/pep-382-2/ 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 proposal):
=============
Another approach considered during revisions to this PEP was to simply rename package directories to add a suffix like
.nsor-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*.nsfiles, and even make it clearer that the directory involved is a namespace portion.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 tools.
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" grounds.
=============
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)
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] PEP 382 specification and implementation complete
- Next message: [Python-Dev] PEP 382 specification and implementation complete
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]