Neil Schemenauer wrote: > I only had time to skim this PEP. Currently I am using import hooks > to load PTL modules (like .py modules but they have a different > extension and need a different compiler). Most of the discussion has > focused on loading .py modules from places other than filesystems. I > was afraid my use case would not get addressed (iu.py doesn't really > work, ihooks.py does). It looks like the hooks proposed by this PEP > are sufficent for my needs. Interesting use case! I wish I had known about it earlier. Can you point me to your code using ihooks, if it's available? I'm actually not so sure the new hook mechanism solves all your problems as well as it could/should. I assume these special modules simply live on sys.path, intermixed with "regular" modules? This would mean you specifically need to extend the builtin sys.path/pkg.__path__ find/load logic, which is something the PEP doesn't cater for (yet). If the special modules live in a special folder, things are easier. Also: special modules will not work when packaged in a zip file (zipimport doesn't come *close* to transparently replacing the file system). If you compile to straight .py[co] (as I assume) and put those in the zip archive, you should be fine, though. This also touches on the modulefinder-like-tools-issue. Your hook should ideally support the get_code(fullname) method, so that packaging tools will be able to deal with it more or less transparently. Obviously the hook need to be installed when running modulefinder-like-tools. (Hmm, this suggests that an external hook registry might be handy, perhaps a *.pth-like trick...) Just
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