[Python-Dev] Thoughts on stdlib evolvement

[Josiah Carlson]

Fernando Perez wrote:
> Josiah Carlson wrote:
>>Fernando Perez wrote:
>>>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?
> 
> 
> Well, I've thought of this (ligthly) mostly as a py3k thing, since it would
> require that 'import email' in the naked fails, as it would become 'import
> std.email', or 'import std.www.email' or whatever.  A plain 'import email'
> would then refer to some third-party 'email' module, not part of the standard
> library.
> 
> Since this would mean a massive break of exisiting code, it would necessarily be
> a py3k issue.  But nonetheless the idea of confinign the stdlib to the 'std'
> namespace does have some appeal, at least to me.

Actually no.

Re: std.*
If there were a single path (or set of paths) know at install time where 
standard library modules are, then that can be placed in a PYSDTLIB 
environment variable (or some other specified place).  Inside Python, 
whenever an import is done relative to std, one merely examines the 
paths offered via the PYSTDLIB environment variable for the looked-for 
module.  For modules/packages in site-packages, one could use another 
name, perhaps "packages" or somesuch, to refer to it.  sys.path is not 
usable as-is because it can contain the path of the module named 
__main__, and is (not uncommonly) modified by user code.

This can be used with a proper import hook, which is turned on 
per-module via a __future__ import, hence no backwards compatibility issues.


What I had been working on is the use of special import semantics for 
non-stdlib/site-packages modules.  Specifically if you were to write 
'mymodule.py' and import your other module 'myothermodule.py' in the 
same path, you would use "from . import myothermodule".  It doesn't 
solve any problems with standard library naming, but it does allow one 
to do cousin imports... "from ..uncle import cousin", as well as all 
sorts of other things, which allows (in writing software) for modules 
and packages to be shared by other packages.

  - Josiah