[stdlib-sig] new package idea: zip
python at rcn.com
Mon Mar 10 03:29:59 CET 2008
> 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".
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.
More information about the stdlib-sig