On Jan 6, 2008 7:23 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote: > >Regarding using common words, either the stdlib grabs these, or > >*nobody* gets to use them (for fear of conflicting with some other 3rd > >party package grabbing the same). > > This isn't quite true; a standalone Python application that isn't > extensible doesn't need to worry about this. And it's standalone > apps that are most likely to claim these common words. (For example, > until recently, Chandler's database library packages were in 'repository.*'.) > > But of course this is still a pretty minor point overall. If the > stdlib does go for deeper nestings, I have a slight preference for > seeing them under std.* or some such rather than top level. But I > don't really see a whole lot of point to doing a major re-org of the > stdlib space to begin with, for the simple reason that package names > are not really categories -- they're *names*. IMO 'from databases > import sqlite' doesn't add any value over 'import pysqlite3' to begin with. > > Worse, it will likely be an attractive nuisance for people saying > "why don't we have databases.Oracle?" and suchlike. And you still > have to remember the names, only now they're longer. And was it > database or databases? Greater uniqueness of names is just another > reason flat is better than nested. :)
Right. Packages are useful if it helps make the sub-names shorter. The email package is a good example: it uses lots of generic names like errors, charset, encoders, message, parser, utils, iterators. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
