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

[Brett Cannon]

On 10/13/06, Talin <talin at acm.org> wrote:
>
> 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.


Actually, I think we can to a certain extent.  What really needs to happen
is the truly important, used modules stay, and of those that are in need of
a rewrite (e.g., urllib and friends), they get cleaned up appropriately.
Everything else we ditch.  This might require a huge voting on the part of
python-dev through a Py3K PEP listing things to remove compared to keep, but
I think we can definitely prune it down.

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.


That's fine.  If there is a desire to toss up the ripped out modules online
for easy re-installation I don't think you will have major arguments.

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.


This is a documentation problem of not having the popen docs point you to
subprocess as a better solution.

I think the negative response has been from the feeling that you want to
strip the stdlib lib heavily.  I personally just want to ditch modules that
have very little value to a large portion of our usebase (who uses
sunaudiodev?).  But I do not want important modules to require some
setuptools install to get at.  For marginalized stuff, fine.  And if someone
steps forward to have a "best of breed" listing that people pull from, then
that's fine as well (but that won't be python-dev; see how long it took to
get sqlite added).

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20061013/c215de72/attachment.htm