[Python-Dev] Thoughts on stdlib evolvement

[Josiah Carlson]

Fernando Perez wrote:
> 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

This generally brings up the intersection of stdlib and nonstdlib naming 
hierarchy.  More specifically, what does "import email" mean? 
Presumably it means to import the email module or package, but from the 
current module directory, or from the standard library?

I posted about this months ago, and got to writing an import hook that 
used a method suggested by Guido by naming things (sys.modules names) 
based on whether they were imported relative to the module with a 
__name__ of '__main__', and using the prefix dot semantics for 
package-relative imports to mean any relative imports.

I eventually got hung up on some nested import bits, and got busy with 
work.  I may have time to hack on it next week to finish the 'proof of 
concept' (currently in the Bay area for work), but if someone wants or 
needs more explanation, I would be happy to offer it.

  - Josiah