On Jan 7, 2008 12:56 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > 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.
I'd be very reluctant to have more "asymmetric" packages like os where the package contains functionality at the top level as well as submodules, because it means that anyone using one of the submodules will pay the price of importing the top-level package. In this example, I can easily see someone using htmlentitydefs without needing htmllib. > Another example is http: > http.lib, http.server.cgi, http.server.base, http.server.simple. That sounds like a good one. > Both examples are grouped because they make sense, but primarily to > make the tail module name simpler. [...] > > 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. Well, that's a little different -- plat-* and lib-tk are not subpackages but subdirectories. For the plat-* subdirs, this is done so that the same logical module name can have different implementations per platform. For lib-tk it was done to make it easier to create a distribution that didn't include any Tk stuff. But the test package structure doesn't follow this lead, and I'm not sure if it still makes sense for lib-tk. OTOH maybe lib-tk could be promoted to being a real package (named tkinter?), with the core tkinter functionality in __init__ and the rest in submodules with names conforming to PEP 8; this is one example where that type of organization actually makes sense. -- --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
