Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 02:10 PM 1/6/2008 -0800, Brett Cannon wrote:
My question becomes whether we want to allow something like this even if we explicitly state people should not use this mechanism to override pre-existing modules. Do we want people tossing stuff into the 'databases' package, or should the packages in the stdlib be considered sacred?
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) 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. 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.
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
On Jan 6, 2008 4:10 PM, Christian Heimes <lists@cheimes.de> wrote:
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.
Why not? 3rd party software can copy the same hierarchy under its own toplevel package, e.g. zope.db, zope.net, etc. Regarding using common words, either the stdlib grabs these, or *nobody* gets to use them (for fear of conflicting with some other 3rd party package grabbing the same).
*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.
Java's example notwithstanding, I don't want "py" or "python" to be part of the stdlib package namespace. *If* (part of) the stdlib has to live under a single distinguished name, pick something like "std" or "core". When I'm using Python I already know I'm using Python, I don't want to be reminded of that fact on every import line.
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.
I see mostly possibilities for abuse here. Linux vendors can install bugfixes or using their own packaging system.
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.
Right.
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.
See my previous post. This is only mildly useful. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sun, Jan 06, 2008 at 04:23:59PM -0800, Guido van Rossum wrote:
I don't want "py" or "python" to be part of the stdlib package namespace. *If* (part of) the stdlib has to live under a single distinguished name, pick something like "std" or "core". When I'm using Python I already know I'm using Python, I don't want to be reminded of that fact on every import line.
When I'm using Jython - am I using Python of Java? After from java.lang import Class should it be from py import exceptions or from core import exceptions ? Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
participants (4)
-
Christian Heimes -
Guido van Rossum -
Oleg Broytmann -
Phillip J. Eby