On 10/13/06, Talin <[EMAIL PROTECTED]> wrote:
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.
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.
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).
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.
-Brett
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
