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 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4