[Python-Dev] Re: Adding Optik to the standard library

Guido van Rossum guido@python.org
Fri, 31 May 2002 00:53:32 -0400

> [Barry A. Warsaw]
> > If that's so, then I'd prefer to see each class in its own module
> > inside a parent package.
> Without trying to open a can of worms here, is there any sort of
> consensus on the use of packages with multiple smaller modules
> vs. one module containing everything? I'm asking about the Python
> standard library, specifically. According to the
> one-class-per-module rule of thumb, there are some Python modules
> that could be refactored into packages. Weighing against that is the
> convenience of importing a single module.

Barry is the proponent of the one-class-per-module rule.  I don't mind
having more classes per module at all; even having the module named
after the "dominant" class doesn't bother me.

A single module containing several classes makes for shorter imports,
e.g. you can write

  from damodule import DaClass

rather than

  from dapackage.DaClass import DaClass

I realize that you can put magic in dapackage's __init__.py that lets
you write

  from dapackage import DaClass

but it's not pretty, and if DaClass is still defined in a module
DaClass.py inside dapackage, there's an unpleasant ambiguity: on the
one hand dapackage.DaClass is a module, on the other hand it's a

Barry's email package avoids the __init__ nastiness but you end up
having to write the rather verbose

  from email.Message import Message

> I'm just wondering if there are any guidelines that should frame
> one's thinking beyond the fairly obvious ones? For example, is the
> standard library an exceptional case because it must appeal to new
> users as well as experts? Does a good part of this issue come down
> to personal preference? Or are there advantages and disadvantages
> that should be documented? (Maybe they already have.)

The standard library grew organically and represents many points of

> Is the current library configuration considered healthy? There are a
> mix of packages and single modules. Are these implementations pretty
> optimal, or would they be organized differently if one had the
> chance to do it all over again?

If I had to do it all over again, I'd probably organize it
differently, but I don't see a point in attempting a massive
reorganization -- it will only upset the users without real benefits
(humans are pretty good at dealing with semi-disorganized data).

--Guido van Rossum (home page: http://www.python.org/~guido/)