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

[Brett Cannon]

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