[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
class!
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
view.
> 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/)