[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages (original) (raw)

Brett Cannon brett at python.org
Tue Jan 8 03:43:07 CET 2008

On Jan 7, 2008 3:47 PM, Guido van Rossum <guido at python.org> wrote:

On Jan 7, 2008 12:56 PM, Brett Cannon <brett at python.org> 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.

Fair enough. Then something like html.lib or html.tools could be had for miscellaneous code.

> Another example is http: > http.lib, http.server.cgi, http.server.base, http.server.simple.

That sounds like a good one.

Great! I think I get what you are after then for the reorg in terms of any new packages coming about.

> 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.

If the platform-specific stuff is made into their own packages (e.g., unix, mac, win, tkinter, etc.) then this can apply generically across the stdlib (sans Modules, of course, unless we eventually change how we handle building extension modules such that they are kept in /Lib as well). I think that would be nice in terms of organization of the code and the documentation as it makes it more obvious which modules are platform-specific.

Is applying this to OS-specific modules work for you like it does for tkinter stuff?

-Brett

More information about the Python-Dev mailing list