Phillip J. Eby wrote: > This is actually an excellent point, given that the actual intended > use of namespace packages is to allow an *organization* to control a > namespace: e.g. zope.* and zc.* packages, osaf.* packages, > etc. Using names that have meaning (like "email" or "databases") > sort of goes against the whole point of namespace packages in the first place. > > For some reason, I wasn't thinking about that when the original post > came through. > > So, now that I've thought about it, I'm -1 on the stdlib using > *top-level* namespace packages to sort out its contents (e.g. > "databases" as a top-level package name)
I don't have a strong opinion as PJE but tend to agree with his point of view. We must not reserve a complete set of top level names and close them for 3rd party software. *Either* we create subject area packages (e.g. databases, web) and open them for 3rd party software *or* we create a top level name space for Python's stdlib and reserve it for our own purpose. For the initial example of "databases.sqlite" I think py.db.sqlite has a nice ring to it. > If we want to allow separately-distributed *upgrades* or bugfix > releases of projects (such as an updated sqlite module), then using > 2nd-level namespace packages like "std.databases.*" would allow that. I like to see a possibility to easily upgrade, bugfix or extend a stdlib package with 3rd party extensions. PEP 297 (http://www.python.org/dev/peps/pep-0297/) contains some useful ideas. > Note, by the way, that this implies that somebody creating their own > Oracle driver would *not* be expected to put it into > std.databases. Again, the whole point of a namespace package is to > reserve that namespace for packages produced by a particular > organization, similar to the way e.g. the 'org.apache.projectname' > packages in Java work. The initial idea behind the new packages for Python 3.0 weren't really based on name space packages. It was more about grouping related modules by subject. Christian _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
