[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages

[Guido van Rossum]

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.

> 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/)