[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages (original) (raw)
Paul Moore p.f.moore at gmail.com
Mon Jan 7 00:12:43 CET 2008
- Previous message: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
- Next message: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 06/01/2008, Brett Cannon <brett at python.org> 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? I am leaning towards not, but that's because I personally like knowing that if I import something from a stdlib namespace it is from the stdlib. I don't want some bug report from a naive user of cxOracle ending up in the stdlib because the import came from the 'databases' package. And I would guess that if you don't consider this a stdlib thing but for any third-party package that other third-party packages would not love other packages mucking with their namespace.
I see the point, but I'm against reserving generic package names like "databases" for the stdlib, unless 3rd parties can add modules in there. Another example might be "gui.tkinter" - why shouldn't "gui.wx" be allowed?
If we want a "guaranteed-stdlib" package form, we should probably have a top-level package, "std" or whatever. That notion has, I believe, been shot down before (no time to look up references now).
Paul.
- Previous message: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
- Next message: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]