"M.-A. Lemburg" wrote: > An example: > > A path importer knows how to scan directories and how to use > a path to tell the correct order. It can maybe also import > .py/.pyc/.pyo files. Now what happens if it finds a shared > lib as module... the usual imputil way would be to delegate > the request to some other importer which can handle shared > libs... but wait: how does the shared lib importer know > where to look ? It will have to rescan the directories, > etc... The above refers to an earlier but still very recent version of imputil. On that basis is is perfectly accurate. Here is another example from my own experience almost identical to the above: 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 libs (aka DLL's in Windows) with names identical to names of *.pyc files in the archive. For example, suppose foo.pyc is in the archive, and foo.dll is in a directory. Suppose sys.path is to be used to decide whether to load foo.pyc or foo.dll. Then an "archive importer" will fail to do this. Specifically you can't see if foo.pyc is in the archive and then check sys.path, nor can you do the reverse. You must call the "archive importer" repeatedly for each element of sys.path and search the directory at the same time. 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