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

[Talin]

Giovanni Bajo wrote:
>> Therefore, you have to obsolete old stuff if you want there to be
>> only One Obvious Way To Do It.
> 
> I'm totally in favor of obsoletion and removal of old cruft from the standard
> library.
> I'm totally against not having a standard library.

Who said anything about not having a standard library?

Right now, Python, as a community, has essentially no means for library 
cruft removal. In order to keep the large body of existing Python 
programs out there still working, we have to keep every module that's 
ever enjoyed even a modicum of popularity, even when something better 
comes along.

Yes, with Py3K we may be able to remove some things, but even there our 
hands are tied - we can't go around breaking things gratuitously, and a 
"Py3K" opportunity only comes around once every 5-10 years or so, if we 
go by our current (small) sample size of release history.

The idea of "easy_install legacy" essentially gives us the library 
equivalent of "from __past__ import ...". It means that any given user 
can easily reconstruct a version of the library that has all of the 
backwards-compatible modules that they would need to run old code, 
without cluttering the library forevermore.

It also does so in a way that doesn't require those old programs to be 
modified, nor does it require any special command-line options to the 
Python executable. Because it's a modification to the Python environment 
instead, it means that even batch files that invoke Python scripts will 
continue to run as intended. All that's required is that when a user 
upgrades to a new version of Python, they also install (or not, if they 
choose) the legacy packages.

Right now, there's just enough duplication in the library to make even 
experienced programmers like me confused. I often find myself using a 
particularly library function, only to later discover that there's a 
better, more recent version that I didn't know about. For example, I 
wanted to parse command-line options, and I opened up the library index, 
did a search on 'opt', and the first thing I came to was 'getopt', and I 
thought "Oh right, getopt, just like in glibc" and proceed to write my 
code using that. A couple days later, I stumble across "optparse", and 
realize I should have been using that instead - if only I had pressed 
the "find next" button a few more times! The same is true for 'popen' 
vs. 'subprocess' and others. So much for OOWTDI.

-- Talin