[Python-3000] Proposal: No more standard library additions

[Phillip J. Eby]

At 08:16 AM 10/15/2006 +0200, Martin v. Löwis wrote:
>Greg Ewing schrieb:
> >> I could see it being a lot easier to maintain e.g. C
> >> compiler plugins for zc.buildout than trying to keep maintaining the
> >> distutils' compiler framework indefinitely.
> >
> > This sounds good. We definitely need *something* with
> > a more modular and better documented architecture than
> > distutils.
>
>I definitely disagree. Why are you calling distutils non-modular?
>It was designed to be modular and extensible,

No, it's designed to be subclassable and customizable.  That is very 
different from being extensible.  setuptools is somewhat 
extensible.  zc.buildout is very extensible.  But the distutils are not 
extensible.  The documentation or lack thereof has nothing to do with it.

"Modular" is a red herring.  The distutils isn't a bad framework, for its 
time.  But it was not designed with extensibility (vs. customizability) in 
mind.

The difference between the two is that an extensible system is one that 
follows the same rules for extenders as it does for its core 
developers.  For example, in the distutils, there are two ways to register 
commands: one for extenders, and one for core developers.  (Actually, there 
are three, as there is yet another way added in Python 2.4 for third 
parties to add commands as well.)

Setuptools, in contrast, has one preferred way to register commands, and it 
follows that way itself.  Core, extenders, and third parties all use the 
same mechanism, so it only needs to be documented once, and the platform is 
more open.  (For backward compatibility, of course, it has to support all 
the other ways that distutils does it.)

Another example is compiler support.  Using the techniques of setuptools 
and zc.buildout, we could allow anybody to write support for a particular C 
compiler abstraction, to e.g. support cross-compilation.  They could 
distribute that support separately and would not have to be a distutils 
developer to do so.  Other people could use that support for their own 
projects without having to bundle it in, and create the massive distutils 
"extensions" used by many larger projects today.

The lack of ability to do this is a characteristic design limitation of the 
distutils (because only core developers of distutils can add new compilers, 
archive formats, etc.).

That doesn't mean the distutils are "bad", it just means that the 
distutils' architecture is not an "architecture of participation".  When a 
system's architecture is designed for collaboration (as opposed to mere 
customization via subclassing) it will have more collaboration happening 
around it.

Two of the biggest Python "community" development trends in recent years, 
setuptools and WSGI, are good demonstrations of how a design can be used to 
promote collaboration, rather than balkanization.  The distutils' design 
promotes balkanization through project-specific customization, but this can 
be turned around with a better design that allows more people to 
participate in development and extension.