On Jan 7, 2008 12:40 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On Jan 7, 2008 12:19 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > > On Jan 6, 2008 8:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > 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. > > > > So only do the 'databases' package if we can change the modules names > > to make it worth it? So whichdb becomes databases.which, dumbdbm > > becomes databases.dumb, etc.? > > Bad example IMO; these are all about relatively simple "dict-on-disk" > APIs, not about (relational) databases. I'd be +0 things like dbm.gnu, > dbm.any, dbm.dumb, dbm.which. >
OK. So an html package could have htmllib for its __init__ (or html.lib), and then have html.entities and html.parser for htmlentitydefs and HTMLParser, respectively. Another example is http: http.lib, http.server.cgi, http.server.base, http.server.simple. Both examples are grouped because they make sense, but primarily to make the tail module name simpler. > > And then extend this to any other > > package that we consider creating? Otherwise leave it out? How would > > that follow for sqlite since that is not going to get any shorter > > thanks to a package? Should it still go into the package for > > organizational purposes? > > If you're asking me, the "organizational purpose" is 100% misguided. > Well that will make the reorg simpler. =) > > In other words, should the stdlib reorg only introduce new packages if > > the majority of modules that go into the package end up with a shorter > > name? > > See what others say. This will be interesting. > > Another reason to have a top-level package would be if there are a lot > of subpackages/submodules. This applies to the xml package for > example. The only place I can see that coming into play is if there is any desire to group OS-specific modules together. Otherwise I think Tk-specific stuff is the only place where this has not been done before. -Brett _______________________________________________ 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
