Phillip J. Eby wrote:
Yes, it's true, zipfile import processing is faster than normal import processing; it is in fact one of the reasons zipfile imports were added to Python, because the zip directories are cached. A zipfile import lookup is a single dictionary lookup, whereas a directory import lookup requires multiple stat() calls. For all practical purposes, zipfiles added to sys.path are free after the initial directory read operation.
OTOH, it does add an overhead on startup, as it will have to read the TOC of all zipfiles on sys.path, atleast if the module you are looking for is in the last zipfile on the path. It then also adds memory overhead, as the TOC of all files is cached in memory.
Note that the need for a .pth is a limitation caused by the requirement to have packages importable at startup. Packages installed in "multi-version" or "deactivated" mode are only added to sys.path upon request and have no impact on startup time. Relatively few eggs *need* to be installed with a .pth file; we are simply in a transitional period where people still expect "installed" packages to be importable without an additional require() operation.
People reasonable will have this expectation for a Debian package. If you install a Debian package with some library, you expect the library to be usable right away.
Finally, I think it's important to note that what Debian should or should not use isn't really relevant to Debian's users, who will quite simply need eggs for many packages. If Debian doesn't provide them, the users will be forced to obtain them elsewhere.
Debian should provide the packages, but not as eggs. For a Debian user, eggs do not add advantages, and for a Debian Developer, they only add additional hassle.
Over time, the number of packages that users need in egg form will continue to increase, and there will be an increasing number of users wanting to know why Debian can't provide them. It's perfectly reasonable not to redo existing Debian packages to use eggs, but for some packages, *not* using eggs is simply not an option.
Debian developers should work with upstream authors to keep a distutils-based setup.py operational. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
