[Python-3000] packages in the stdlib

[Terry Reedy]

"Aaron Bingham" <bingham at cenix-bioscience.com> wrote in message 
news:447F0FC4.1030906 at cenix-bioscience.com...
> I'm confused.  As far as I can see, a reserved prefix (the "py" or
> "stdlib" package others have mentioned) is the only reliable way to
> avoid naming conflicts with 3rd-party packages with a growing standard
> library.

True, but..

> I suspect we wll be going round and round in circles here as
> long as a reserved prefix is ruled out.  IMO, multiple reserved prefixes
> ("net", "gui", etc.) is much worse than one.

But much better than a hundred or more ;-)

>  Could someone please
> explain for my sake why a single reserved prefix is not acceptable?

Because you have to type it over and over.  Because it is pure nuisance for 
simple usage of python with imports only or almost only from the standard 
lib.  Because it does nothing to organize the standard lib.  Because it 
would be in addition to any set of organizing prefixes such as 'net', 
'gui', etc, which are much more informative from a user viewpoint.

There are two separate issues being discussed here:
1) reducing/eliminating name clashes between stdlib and other modules;
2) organing the stdlib with a shallow hierarchy.

For the former, yes, a prefix on stdlib modules would work, but this most 
common case could/should be the default.  Requiring instead a prefix on all 
*other* imports would accomplish the same.  For instance, 's' for imports 
from site-packages and 'l' for imports of local modules on sys.path (which 
would then not have lib and lib/site-packages on it).

But the problem I see with this approach is that is says that the most 
important thing about a module is where it comes from, rather than what I 
does.

For the latter (2 above), I think those who want such mostly agree in 
principle on a mostly two-level hierarchy with about 10-20 short names for 
the top-level, using the lib docs as a starting point for the categories

The top level files should have nice doc strings so that import xyzt; 
help(xyz) gives a nice list of the contents of xyz.  To deal with the 
problem of cross-categorization, this doc couldalso have a 'See Also' 
section listing modules that might have been put in xyz and might be sought 
in xyz but which were actually put elsewhere.

Up in the air is the question of plugging in other modules not included in 
the stdlib.  With useful categories, this strikes me as a useful thing to 
do.  From a usage viewpoint, what a module does is more important than who 
wrote it and who distributes it.  When it become trivial to grab and 
install non-stdlib modules, then the distinction between stdlib and not 
becomes even less important.  If there is an approved list of plugins for 
each top level package, that can be included in the doc as well.  What 
would be really nice is if trying to import an uninstalled approved module 
would trigger an attempt to download and install it (in the appropriate 
package.)

Terry Jan Reedy