[Python-Dev] Thoughts on stdlib evolvement
Fernando Perez
fperez.net at gmail.com
Tue Jun 7 02:12:26 CEST 2005
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
More information about the Python-Dev
mailing list