On 06/01/2008, Brett Cannon <[EMAIL PROTECTED]> 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 cx_Oracle 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. _______________________________________________ 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
