[Distutils] formencode as .egg in Debian ??

[Phillip J. Eby]

At 06:57 PM 11/22/2005 +0100, Martin v. Löwis wrote:
>Ian Bicking wrote:
>>Maybe an easier way to understand this (at least my impression) is that 
>>zip files are treated as read-only.  Any directory on sys.path gets 
>>scanned everytime a new module is imported.  And you never know if 
>>someone added something, so you do it all over again each time.  A zip 
>>file is scanned only once.
>
>The difference is that a directory inside site-python is not scanned
>*at all* if the application looks for some other package. Only the
>top-level site-python directory is read, and it is not scanned, but
>instead a lookup operation directly asks for the subdirectory with
>the package name.
>
>If you have many zipfiles on sys.path, all applications will suffer
>from having to read the TOC of all those zipfiles, even if they need
>none of them. OTOH, if you had packages inside site-python, the
>contents of the unused packages is simply ignored.

I'm sorry, but this is, shall we say, "fact challenged"?  .pth files' 
contents are added to the *end* of sys.path.  This means that stdlib 
imports and normal site-packages imports are satisfied *before* any 
hypothetical overhead from .pth entries, whether they're zipfiles or 
directories.  If Python never reaches the .pth entries at runtime, it will 
not even read the zipfile TOCs, let alone attempting to stat() for 
contained packages.

Please check your facts before spreading untruths like this - a simple 
reading of PEP 302 and site.py should make it clear to you that the only 
absolute startup overhead being added here is the reading of the .pth file 
itself - which I've been encouraging vendors to maintain as a single .pth 
file rather than having individual .pth files for each package.