> 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. > > > [Efficiency] > > > 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. - Gordon
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4