[Python-Dev] Re: Adding Optik to the standard library

[Barry A. Warsaw]

[Trimming recipients to just python-dev... BAW]

>>>>> "PKO" == Patrick K O'Brien <pobrien@orbtech.com> writes:

    PKO> Without trying to open a can of worms here, is there any sort
    PKO> of consensus on the use of packages with multiple smaller
    PKO> modules vs. one module containing everything?

It's an interesting topic, to be sure, and no doubt will generate some
nice cooked (charred?) worms.  I'll only describe my own thoughts on
the matter.

I personally like files in bite-sized chunks, which means when they
get to be more than one or a few tall emacs screenfuls, I start to get
the urge to split things up.  I'm probably somewhat influenced too by
my early C++ days when we adopted a one class per .h file (and one
class implementation per .cc file).  IIRC, Objective-C also encouraged
this granularity of organization.  Even earlier influences include the
FORTH convention of organizing everything into 1024 byte blocks, and
that's it!  For whatever reason, I definitely prefer to edit more
smaller files than fewer large files (but all in moderation!), and the
class seems to be a good organizational structure around which to
split things.

    PKO> I'm just wondering if there are any guidelines that should
    PKO> frame one's thinking beyond the fairly obvious ones? For
    PKO> example, is the standard library an exceptional case because
    PKO> it must appeal to new users as well as experts? Does a good
    PKO> part of this issue come down to personal preference? Or are
    PKO> there advantages and disadvantages that should be documented? 
    PKO> (Maybe they already have.)

I think most of the standard modules are special because they were
written before Python had a good (or any!) package system.  For legacy
modules that export lots of classes, there's probably little benefit
to refactoring them into packages.  That might change if we want to
start separating things out into separately installable distutilized
packages though.  The package seems to be the smallest convenient unit
for distutils.

    PKO> Is the current library configuration considered healthy? 
    PKO> There are a mix of packages and single modules. Are these
    PKO> implementations pretty optimal, or would they be organized
    PKO> differently if one had the chance to do it all over again?

Some of the newer packages are designed as packages because they're
complex and big: distutils, xml, email, compiler.  That makes perfect
sense to me.  It's possible something like Cookie.py if re-done
/might/ make sense as a package, but I'm not sure.  I doubt it makes
much sense for something like smtplib.py to ever be a package, and
besides other than exceptions, it only exports one main class.

BTW, exceptions are...exceptions!  I don't have much problem lumping
all of a package's exception classes in one module.

so-yeah-it-probably-is-personal-preference-ly y'rs,
-Barry