On 7/22/2011 2:40 AM, rantingrick wrote:
On Jul 22, 12:45 am, Terry Reedy<tjre...@udel.edu> wrote:
Let me give some overall comments rather than respond point by point.
Python-dev is a volunteer *human* community, not a faceless corporation,
with an ever-changing composition (a very mutable set;-).
It is too small, really, for the current size of the project.
Python 3 was mostly about syntax cleanup. Python-dev was not large
enough to also do much stdlib cleanup. With the syntax moratorium,
attention *was* focused on the stdlib and problems were found. Some
functions names was actively incorrect (due to shift from str-unicode to
bytes-strings). Some functions were undocumented and ambiguous as to
their public/private status. Some deprecations were made that will take
effect in 3.3 or 3.4.
This introduced the problem that upgrading to Python 3 is no longer a
single thing. We really need 2to3.1 (the current 2to3), 2to3.2, 2to3.3,
etc, but someone would have to make the new versions, but no one,
currently, has the energy and interest to do that. So people who did not
port their 2.x code early now use the problem of multiple Python 3
targets as another excuse not to do so now. (Actually, most 2.x code
should not be ported, but their are more libraries that we do need in 3.x.)
The way to revamp a module is to introduce a new module. Any anythong
now must be released first on PyPI. This has precedent. In 2.x days,
urllib2 was an upgrade to urllib though I do not if it was on PyPI.
For 3.x, Stephen Behnel's argparse supercedess optparse, but the latter
remains with the notice in red: "Deprecated since version 2.7: The
optparse module is deprecated and will not be developed further;
development will continue with the argparse module.". Argparse was first
released on pypi and versions compatible with earlier than 2.7 and 3.2
remain there.
The new 3.3 module 'distribute' is a renamed distutils2. It is now on
PyPI, where it has been tested with current and earlier versions and it
will remain there even after 3.3 is released.
An archive module should be released or at least listed on PyPI. It will
thus be available wherther or not incorporated into the stdlib. (Many
useful modules never are, partly because the authors recognize that
there are disadvantages as well as advantages to being in the stdlib.)
It should be compatible with at least 3.1+ so that people can use it and
be compatible with multiple 3.x versions. Starting with a version < 1.0
implies that the api is subject to change with user experience.
This does not preclude also making compatible changes *also* in stdlib
modules. And as I mentioned before, there are already a lot of bug and
feature requests on the tracker. Merely putting a new face (api) on a
sick pig is not enough.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
