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

[Talin]

Aahz wrote:
> On Mon, Oct 16, 2006, "Martin v. L?wis" wrote:
>> Greg Ewing schrieb:
>>> Unless the basic structure is so far from what's needed that it can't
>>> be reasonably fixed.
>> See, and I believe this isn't the case for distutils.
> 
> Can you suggest a good mechanism for resolving the deadlock?  We have the
> primary maintainer (and some other users) claiming that distutils is a
> mess that needs rewriting.  You think it doesn't, but based on other
> comments you've made, I believe you don't have available time.  I haven't
> seen anyone else agreeing with you.

One thing that I think would be helpful is if there were a requirements 
doc for distutils. Any attempt to refactor distutils is going to fail 
IMHO, unless the person doing the refactoring knows exactly what it 
needs to accomplish, and as we all know, its not always possible to 
infer from an existing system (even a documented one) what its 
*supposed* to do, as opposed to what it actually does now. I know that 
in my case, I have a hard enough time even understanding the existing 
distutils docs - if I were to foolishly attempt to create a replacement, 
what would happen is that I would end up solving my specific problems 
and no one else's.

I would suggest perhaps a wiki page or discussion devoted to collecting 
requirements and use cases for a new distutils. This should incorporate 
not only the existing distutils requirements, but should also 
incorporate lessons from the creation of setuptools, and an awareness of 
what's going on in the refactoring of the import machinery.

One thing to discuss would be how to handle backwards compatibility; I 
see three alternatives: (1) Make the APIs of the new system match the 
old one, (2) Make a "compatibility module" that plugs in to the new 
system, allowing development of a new API while maintaining the existing 
one, and (3) leave the existing distutils system in place, but 
deprecated in favor of the new one.

If the new system is enough better than the previous one, I don't see 
that there will be a huge problem getting people to migrate over, as 
long as the new system supports older versions of Python as well as 
Py3k. Given that many distutils scripts are generated from boilerplate 
or templates, automatic conversion may also be possible.

Once the requirements are in place and there is rough consensus on what 
the tool actually needs to do, we can start generating PEPs that attempt 
to meet those requirements.

-- Talin