[Python-Dev] Thoughts on stdlib evolvement

[Fernando Perez]

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