Inconsistencies between zipfile and tarfile APIs

[Terry Reedy]

On 7/22/2011 2:40 AM, rantingrick wrote:
> On Jul 22, 12:45 am, Terry Reedy<tjre... at 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