[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/