Greg Stein wrote: > > On Sat, 4 Dec 1999, James C. Ahlstrom wrote: > >... > > One possible archive file format holds its list of archived > > *.pyc file names as keys in a dictionary. This is simple and > > efficient, but fails to correctly address the problem of shared > What? The archive is independent of each .pyc's original position in > sys.path. There is no reason/need to carry that information into an > archive. > > If the archive contains "foo", then you're done. If it doesn't, then move > on to the next element of sys.path (directory or Importer instance) and > look there. > > Basically: if you deploy an archive, then all of its files will take > precedence over any file found later on sys.path. This is exactly what > sys.path is about: establishing precedence. Sorry, I am a little slow today. My daughter got me up at 6 am to work on her computer video editor. No disk space, fragmentation, 2 gig limit on AVI files, ........ Are you saying this? If foo is imported, the archive importer is consulted first to see if it can provide foo. If not, sys.path is searched for foo.pyc, foo.pyl etc., and if foo.pyl is found, then its contents are added to the single archive importer dictionary. The order of addition to the archive dictionary is determined by sys.path, and duplicate names are not entered because they lie later on sys.path. But once a file is recognized as in an archive, it effectively precedes all of sys.path. Or this? If foo is imported, sys.path is searched for foo.pyc, foo.pyl, etc., and also all archive files found at each element of sys.path are searched for foo. If "bar" is imported, it may be found in foo.pyl. That is, there is an instance of an archive importer for each element of sys.path. What if the user names an archive file not on sys.path? What order does it have? JimA
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