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

[Brett Cannon]

On Wed, Oct 27, 2010 at 03:42, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 26 Oct 2010 22:06:37 -0400
> Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
>>
>> 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.
>
> Are you saying that it has become a pile of medium-sized balls of mud?
> I would like to say thanks for the mud, Michael! It's high quality mud
> for sure.

I realize I am a little late in this reply but issue 10273 linked to
this and so now I am actually bothering to read this thread since it
felt like bikeshedding when the thread began.

I think the issue here is that the file structure of the code no
longer matches the public API documented by unittest. Personally I,
like most people it seems, prefer source files to be structured in a
way to match the public API. In the case of unittest Michael didn't.
He did ask python-dev if it was okay to do what he did, we all kept
quiet, and now we have realized that most of us prefer to have files
that mirror the API; lesson learned. But Python 2.7 shipped with this
file layout so we have to stick with it lest we break any imports out
there that use the package-like file structure Michael went with
(which we could actually document and use if we wanted now that
Michael has already broken things up). Reversing the trend by sticking
all the code into unittest/__init__.py and then sticking import shims
into the existing modules would be a stupid waste of time, especially
considering the head maintainer of the package likes it the way it is.

So basically it seems like we have learned a lesson: we prefer to have
our code structured in files that match the public API. I think that
is a legitimate design rule for the stdlib to follow from now on, but
in the case of unittest it's too late to change it back (and it's a
minor price to pay to learn this lesson and to have Michael
maintaining unittest like he has been, plus we could consider using
the new structure so that the public API matches the file structure
when the need arises).