We have to files related to zip files: zipfile and zipimport. Should we bother to consolidate? The problem is the obvious names conflict with built-in type and a keyword, respectively. A possibility is:
zipfile -> zip.filer zipimport -> zip.importer
But I don't know if that is really an improvement. What do other people think?
-Brett
On 09/03/2008, at 19:13, Brett Cannon wrote:
We have to files related to zip files: zipfile and zipimport. Should we bother to consolidate? The problem is the obvious names conflict with built-in type and a keyword, respectively. A possibility is:
zipfile -> zip.filer zipimport -> zip.importer
But I don't know if that is really an improvement. What do other people think?
Although both modules somehow work with zip files they do completely different thing. Better would be to put zipimport with the import machinery and zipfile with tar or something.
-- Leonardo Santagada
On Mar 9, 2008, at 7:21 PM, Leonardo Santagada wrote:
Although both modules somehow work with zip files they do completely different thing. Better would be to put zipimport with the import machinery and zipfile with tar or something.
Agreed on this as well. The modules have no substantial usage similarities.
-Fred
Le dimanche 09 mars 2008 à 15:13 -0700, Brett Cannon a écrit :
We have to files related to zip files: zipfile and zipimport. Should we bother to consolidate? The problem is the obvious names conflict with built-in type and a keyword, respectively. A possibility is:
zipfile -> zip.filer zipimport -> zip.importer
But I don't know if that is really an improvement. What do other people think?
I don't see the point since the functionality is so different (and I don't think zipimport in used in much application-level code). Also, "filer" sounds horrible.
On Sun, Mar 9, 2008 at 6:13 PM, Brett Cannon brett@python.org wrote:
We have to files related to zip files: zipfile and zipimport. Should we bother to consolidate? The problem is the obvious names conflict with built-in type and a keyword, respectively. A possibility is:
zipfile -> zip.filer zipimport -> zip.importer
But I don't know if that is really an improvement. What do other people think?
I don't think it's an improvement either.
-- Alexandre
On Sun, Mar 9, 2008 at 5:52 PM, Alexandre Vassalotti alexandre@peadrop.com wrote:
On Sun, Mar 9, 2008 at 6:13 PM, Brett Cannon brett@python.org wrote:
We have to files related to zip files: zipfile and zipimport. Should we bother to consolidate? The problem is the obvious names conflict with built-in type and a keyword, respectively. A possibility is:
zipfile -> zip.filer zipimport -> zip.importer
But I don't know if that is really an improvement. What do other people think?
I don't think it's an improvement either.
OK. It was a shot in the dark anyway. It was the only other package idea I could think of that had any form of a chance of working.
-Brett
We have to files related to zip files: zipfile and zipimport. Should we bother to consolidate? The problem is the obvious names conflict with built-in type and a keyword, respectively. A possibility is:
zipfile -> zip.filer zipimport -> zip.importer
But I don't know if that is really an improvement. What do other people think?
If you go down this road, then make it a compression package and add bz2, gzip, etc. There was a definite improvement when hashlib was introduced and a common API for hashing routines was enforced. But, simply packaging two completely different zip modules is of dubious benefit.
Here's a general comment on the new package proposals like zip and cookie. When people are looking for stdlib improvements, I don't think they had in mind introducing a new package everytime there were two related modules. Packaging is not free -- it complicates importing, searching for source files, and makes the user have to rememember both the module name and the package name.
For me, the searching part really bites. At work, we have a utils package which consists of a dozen unrelated utility files. When you see code like "from utils import reversedict" you don't automatically know which module to look at to find the source code to see what it does. Likewise, the multilayer directory structure complicates using grep (it's no fun always writing find . -name "*py" | xargs grep 'sometext').
Also, packaging exacerbate the existing annoyance that occurs when a class name closely corresponds to a module name. It already feels redundant to write "from zipfile import ZipFile". It will be even more annoying to write "from zip.zipfile import ZipFile". Yucko!
IOW, the conceptual benefits of grouping theme related modules can be more than offset by the expense of introducing another level of indirection. Packaging should be a last resort rather than a first resort.
Raymond
participants (6)
-
Alexandre Vassalotti -
Antoine Pitrou -
Brett Cannon -
Fred Drake -
Leonardo Santagada -
Raymond Hettinger