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

[R. David Murray]

On Tue, 26 Oct 2010 23:37:10 -0400, Barry Warsaw <barry at python.org> wrote:
> On Oct 26, 2010, at 09:54 PM, Antoine Pitrou wrote:
> >I think it comes down to the preference of whoever works the most
> >actively on it. Michael is the most active contributor to unittest by
> >far, and I suppose he prefers it to be split into several submodules.
> 
> And that seems perfectly reasonable to me, especially if the alternative were
> that Michael was so frustrated with a massive single .py file that it
> discouraged him from working on it.
> 
> If done well, a split can help improve the readability and discoverability of
> the code.  I shudder at the madness that a single email.py file would cause.

To put your mind at ease, Barry, I'd not want to do that either :)

But by (IMO good) design Generator, FeedParser, and Message are all
supposed to be independent (use only each other's public APIs).  And
Header can be (and is, I think) used without the other pieces of email,
as is true for other of the helper modules (base64mime, quoprimime, etc).
On the other hand, I have no clue why 'iterators.py' exists :)

The one that bugs me most, though, is MIME.  Combining all the mime
stuff into one file seems like it would be a big win (not that it's
possible, now).  What is the benefit of email.mime.text.MIMEText over
email.mime.MIMEText, when each of the files in the mime package consists
of a single subclass?

So, to clarify, like Raymond I'm not saying that packages are always bad.
I'm just saying that packages are also not always good; and, further,
that the number of lines of code in a file should, IMO, have nothing to
do with the decision as to whether or not to create a package.

--
R. David Murray                                      www.bitdance.com