Gordon McMillan wrote:
[no *.py files]
You also can't import source files *.py from a zip archive.
Apparently some Linuxes / RPM distributions don't deliver .pyc's or .pyo's. Since they're installed as root and run as some-poor-user, I'm afraid there are quite a few installations running off .py's all the time. So while it's definitely sub- optimal, I'm not sure it should be outlawed.
For Linux/RPM's I think shipping a library directory is better than a zip archive. It is easier to hack on a directory. I think of zip archives as a way to distribute packages, and as a replacement for freeze.
There's no reason to believe that telling a Linux distribution maintainer that they "shouldn't" do it that way will be successful. Heck, he might be a Perl monkey on KP <wink>.
OTOH, maybe we should allow *.py to satisfy imports even if it is slow and invisible.
The key is the archive name from sys.path joined with the file name (including any subdirectories) within the archive.
DIfferent spellings of the same path are possible in a filesystem, but not in a dictionary. A bit of "harmless" tweaking of sys.path could render an archive unreachable.
True, but I have little sympathy for case-insensitive file systems. Tweaking of sys.path will have to be done with care. It helps that the '/' character is always used in zip, and both backslash and colon ":" are illegal in zip archive names.
You don't need case-insensitive for this to come up. Relative paths vs. absolute paths; or paths that need norm-ing.
And then you've got the mac which uses a different path syntax, and even slightly different path semantics.