"Aaron Bingham" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
