Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #10141
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Subject | Re: Inconsistencies between zipfile and tarfile APIs |
| Date | 2011-07-22 15:33 -0400 |
| References | <5fd8e664-c855-41a2-9d8b-36d4c486f0b9@n35g2000yqf.googlegroups.com> <mailman.1344.1311308080.1164.python-list@python.org> <3241cbe4-9829-438b-ac0e-a0b87aff62d9@q15g2000yqk.googlegroups.com> <mailman.1347.1311313569.1164.python-list@python.org> <dc3861c9-cd36-4a42-b020-b3b008b85225@12g2000yqr.googlegroups.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.1384.1311363231.1164.python-list@python.org> (permalink) |
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
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PyWart 1001] Inconsistencies between zipfile and tarfile APIs rantingrick <rantingrick@gmail.com> - 2011-07-21 20:46 -0700
Re: [PyWart 1001] Inconsistencies between zipfile and tarfile APIs Corey Richardson <kb1pkl@aim.com> - 2011-07-22 00:13 -0400
Re: Inconsistencies between zipfile and tarfile APIs rantingrick <rantingrick@gmail.com> - 2011-07-21 21:48 -0700
Re: Inconsistencies between zipfile and tarfile APIs Corey Richardson <kb1pkl@aim.com> - 2011-07-22 01:05 -0400
Re: Inconsistencies between zipfile and tarfile APIs rantingrick <rantingrick@gmail.com> - 2011-07-21 22:58 -0700
Re: Inconsistencies between zipfile and tarfile APIs Lars Gustäbel <lars@gustaebel.de> - 2011-07-22 10:49 +0200
Re: Inconsistencies between zipfile and tarfile APIs rantingrick <rantingrick@gmail.com> - 2011-07-22 10:38 -0700
Re: Inconsistencies between zipfile and tarfile APIs Terry Reedy <tjreedy@udel.edu> - 2011-07-22 01:45 -0400
Re: Inconsistencies between zipfile and tarfile APIs rantingrick <rantingrick@gmail.com> - 2011-07-21 23:40 -0700
Re: Inconsistencies between zipfile and tarfile APIs Corey Richardson <kb1pkl@aim.com> - 2011-07-22 03:19 -0400
Re: Inconsistencies between zipfile and tarfile APIs Terry Reedy <tjreedy@udel.edu> - 2011-07-22 15:33 -0400
Re: Inconsistencies between zipfile and tarfile APIs Ned Deily <nad@acm.org> - 2011-07-22 14:17 -0700
Re: Inconsistencies between zipfile and tarfile APIs Terry Reedy <tjreedy@udel.edu> - 2011-07-22 20:31 -0400
Re: Inconsistencies between zipfile and tarfile APIs Ryan Kelly <ryan@rfk.id.au> - 2011-07-22 15:56 +1000
Re: [PyWart 1001] Inconsistencies between zipfile and tarfile APIs Lars Gustäbel <lars@gustaebel.de> - 2011-07-22 10:26 +0200
Re: Inconsistencies between zipfile and tarfile APIs rantingrick <rantingrick@gmail.com> - 2011-07-22 10:11 -0700
Re: Inconsistencies between zipfile and tarfile APIs Chris Angelico <rosuav@gmail.com> - 2011-07-23 03:23 +1000
Re: Inconsistencies between zipfile and tarfile APIs Chris Angelico <rosuav@gmail.com> - 2011-07-23 03:25 +1000
Re: [PyWart 1001] Inconsistencies between zipfile and tarfile APIs Thomas Jollans <t@jollybox.de> - 2011-07-22 12:31 +0200
Re: [PyWart 1001] Inconsistencies between zipfile and tarfile APIs Tim Chase <python.list@tim.thechases.com> - 2011-07-22 06:25 -0500
Re: [PyWart 1001] Inconsistencies between zipfile and tarfile APIs Terry Reedy <tjreedy@udel.edu> - 2011-07-22 15:49 -0400
csiph-web