On woensdag, dec 18, 2002, at 16:55 Europe/Amsterdam, Just van Rossum wrote: > The new import hooks are not easily integrated in the existing > imp.find_module() and imp.load_module() calls. It's questionable > whether > it's possible at all without breaking code; it is better to simply add > a > new function to the imp module. The meaning of the existing > imp.find_module() and imp.load_module() calls changes from: "they > expose > the builtin import mechanism" to "they expose the basic *unhooked* > builtin import mechanism". They simply won't invoke any import hooks. A > new imp module function is proposed under the name "find_module2", with > is used like the following pattern: > > loader = imp.find_module2(fullname, path) > if loader is not None: > loader.load_module(fullname) If we want to use this for freeze-like functionality then the loader will also need a method (or methods) that at the very least return (for modules for which it makes sense) either the source code for the module or a file-like object that can be used to read the source code. -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
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