[Types-sig] import vs include (was: RFC Comments)
Greg Stein
gstein@lyra.org
Thu, 30 Dec 1999 10:38:59 -0800 (PST)
On Thu, 30 Dec 1999, skaller wrote:
>...
> In this 'two pass' model, it is inconsistent to
> 'import' a module in pass 1, since 'importing' a module
> requires a recursive tranlation pass involving TWO passes,
> and we know that the second pass can even involve recursive
> module execution. So it isn't _possible_ to import
> a module during pass 1. It won't work.
Python importing does *not* allow recursive module execution.
a.py:
import b
some_code()
b.py:
import a
more_code()
Let's say that you import a.py. b will be imported, the "import a" will
establish a reference to the "a" module (which is incomplete at that point
in time), and then more_code() is executed. The import of b completes and
some_code() is then executed. After a.py completes, the module is then
filled in and becomes available to other modules (such as b.py).
[ note that if you *run* a.py, it is named __main__ so b's import will
grab something different ]
Given that recursive module execution cannot occur, there is no problem in
doing a real import and acquiring interface information from the imported
module. In other words: I agree with Paul that we do not need to separate
the notions of import and include.
In check.py, however, I do not plan to perform a true import. Interfaces
of other modules must be specified in a .pi file, or check.py must be
allowed to parse and construct an interface from the target module.
[ I'd rather not open/read/parse/extract an interface from another module
because it would definitely impact the performance too much. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/