The class isn't really the unit of reuse. The old
one-class-per-file rules from C++ aren't helpful for good
reusable design. They are for optimizing compiling and making.
This is great book on large-scale design considerations. Much
of it is C++ specific, but parts apply to Python.
Large-Scale C++ Software Design, John Lakos Addison-Wesley,
Paperback, Published July 1996, 845 pages, ISBN 0201633620.
The module of related classes is the unit of reuse. A cluster
of related modules can make sense for a large, complex reusable
component, like an application program.
As a user, anything in a module file that is not class
definition (or the odd occaisional convenience function) is a
show-stopper. If there is some funny business to implement
submodules, that ends my interest. Part of the open source
social contract is that if I'm going to use it, I'd better be
able to support it. Even if you win the lottery and retire to a
fishing boat in the Caribbean.
The question of <was>Optik</was><is>options</is> having several
reusable elements pushes my envelope. If it's job is to parse
command line arguments, how many different reusable elements can
their really be? Perhaps there are several candidate modules
here. It seems difficult to justify putting them all into a
library. The problem doesn't seem complex enough to justify a
complex solution.
--- "Patrick K. O'Brien" <pobrien@orbtech.com> wrote:
> [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.
>
> 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.)
>
> 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?
>
> Just curious.
>
> ---
> Patrick K. O'Brien
> Orbtech
>
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
=====
--
S. Lott, CCP :-{)
S_LOTT@YAHOO.COM
http://www.mindspring.com/~slott1
Buccaneer #468: KaDiMa
Macintosh user: drinking upstream from the herd.
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4