[stdlib-sig] new package idea: zip

[Raymond Hettinger]

> 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