[Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

[Alexander Belopolsky]

On Tue, Oct 26, 2010 at 5:37 PM, Fred Drake <fdrake at acm.org> wrote:
> On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>> I find the big-ball-of-mud style development, where everything lives inside
>> huge monolithic modules, very painful. I also think that it is an extremely
>> bad example for new developers.
>
> Gadzooks, Michael!  Something else we agree on.  2000-line modules are
> a source of maintenance pain.
>

While I appreciate your and Michael's eloquence, I don't really see
why five 400-line modules are necessarily easier to maintain than one
2000-line module.  Splitting code into modules is certainly a good
thing when the resulting modules can be used independently.  This
helps users write leaner programs, reduces mental footprint of
individual modules, etc, etc.   The split unittest module does not
bring any such benefits.  It still presents a single "big-ball-of-mud"
namespace, only rather than implemented in a single file, it is now
swept in from eight different files.

If instead, unittest module was split into several top level modules
so that test cases can be defined without pulling in test runner
machinery  and third party test runners could avoid importing
irrelevant text runners, that would qualify as an improvement in my
book, but probably not big enough to justify breaking compatibility.

While maintainers' convenience is a valid valid concern and some level
of idiosyncrasy is healthy to allow active maintainers to code in
their preferred style, I think users' convenience should come first
when it conflicts with that of maintainers.  Remember, code is written
once and read many.  This is particularly true about stdlib.  A minor
inconvenience of finding the right place to stick a new function in a
large file does not in my view overweights a major inconvenience of
not having all pieces in one place neatly organized in a linear order.