Skip Montanaro wrote: > I wouldn't mind a stdlib that defined a set of top-level packages (some of > which might be wholly unpopulated by modules in the standard distribution) > It might, for example, define a gui package and gui.Tkinter and gui._tkinter > modules, leaving the remainder of gui namespace available for 3rd party > modules. Such a scheme would probably work best if there was some fairly > lightweight registration/approval process in the community to avoid needless > collisions. For example, it might be a bit confusing if two organizations > began installing their packages in a subpackage named gui.widgets. An > unsuspecting person downloading an application that used one version of > gui.widgets into environment with the conflicting gui.widgets would run into > trouble.
I've wondered if it wouldn't be better if the std lib were all stuffed into its own namespace: from std import urllib If a more structured approach is desired, it could be from std.www import urllib for example. But having std. as the top-level namespace for the stdlib, could simplify (I think) life a lot in the long run. If a decision for a more structured namespace is made, then it might be nice to have the same top-level structure in site-packages, albeit empty by default: from std.www import foo -> standard library www packages from www import bar -> third-party www packages Third-party packages can still be put into base site-packages, of course, but developers could be encouraged to transition into putting things into these categories. This would also ease the process of 'staging' a module as external for a while before deciding whether it meets the requirement for being put into the stdlib. Just an idea (sorry if it's been discussed and shot down before). best, f _______________________________________________ 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
