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

Alexander Belopolsky alexander.belopolsky at gmail.com
Wed Oct 27 04:06:37 CEST 2010


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.



More information about the Python-Dev mailing list