<br><br><div><span class="gmail_quote">On 10/13/06, <b class="gmail_sendername">Talin</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Giovanni Bajo wrote:<br>>> Therefore, you have to obsolete old stuff if you want there to be<br>>> only One Obvious Way To Do It.<br>><br>> I'm totally in favor of obsoletion and removal of old cruft from the standard
<br>> library.<br>> I'm totally against not having a standard library.<br><br>Who said anything about not having a standard library?<br><br>Right now, Python, as a community, has essentially no means for library<br>
cruft removal. In order to keep the large body of existing Python<br>programs out there still working, we have to keep every module that's<br>ever enjoyed even a modicum of popularity, even when something better<br>comes along.
<br><br>Yes, with Py3K we may be able to remove some things, but even there our<br>hands are tied - we can't go around breaking things gratuitously, and a<br>"Py3K" opportunity only comes around once every 5-10 years or so, if we
<br>go by our current (small) sample size of release history.</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The idea of "easy_install legacy" essentially gives us the library<br>
equivalent of "from __past__ import ...". It means that any given user<br>can easily reconstruct a version of the library that has all of the<br>backwards-compatible modules that they would need to run old code,
<br>without cluttering the library forevermore.</blockquote><div><br>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.<br></div>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It also does so in a way that doesn't require those old programs to be<br>modified, nor does it require any special command-line options to the
<br>Python executable. Because it's a modification to the Python environment<br>instead, it means that even batch files that invoke Python scripts will<br>continue to run as intended. All that's required is that when a user
<br>upgrades to a new version of Python, they also install (or not, if they<br>choose) the legacy packages.<br><br>Right now, there's just enough duplication in the library to make even<br>experienced programmers like me confused. I often find myself using a
<br>particularly library function, only to later discover that there's a<br>better, more recent version that I didn't know about. For example, I<br>wanted to parse command-line options, and I opened up the library index,<br>
did a search on 'opt', and the first thing I came to was 'getopt', and I<br>thought "Oh right, getopt, just like in glibc" and proceed to write my<br>code using that. A couple days later, I stumble across "optparse", and
<br>realize I should have been using that instead - if only I had pressed<br>the "find next" button a few more times! The same is true for 'popen'vs. 'subprocess' and others. So much for OOWTDI.</blockquote><div>
<br>This is a documentation problem of not having the popen docs point you to subprocess as a better solution.<br></div><br></div>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).