Mike Meyer wrote:
"max(01)*" <[EMAIL PROTECTED]> writes:
Peter Hansen wrote:
max(01)* wrote:
hi everybody.
suppose that code-1.py imports code-2.py and code-3.py (because it
uses names from both), and that code-2.py imports code-3.py.
if python were c, code-1.c should only *include* code-2.c, because
the latter in turns includes code-3.c.
inclusion of modules in c is a purely preprocessing textual matter
(compilation is deferred to after the fact), i guess, so that such
things are possible. import of modules in python is a different
beast, so the "redundancy" is (i think) necessary.
any comment/suggestion/idea?
You're mixed up about this whole idea.
that's why i am asking for advice here.
my concern was motivated by a (clumsy) attempt to understand the
difference of mechanism between the approach to modular programming in
a more "traditional" language (c) and python.
[Names changed to be valid python module names.]
I feel I ought to point out that you don't really *have* to import the
code_3.py in code_1.py. You can get to things code_3.py in code_1.py
as code_2.code_3.<thing>.
oh. it never occured to me. interesting i must say...
The semantic behavior of "include" in C is the same as "from module
import *" in python. Both cases add all the names in the included
namespace directly to the including namespace. This usage is
depreciated in Python, because it leads to problems figuring out where
a specific variable came from.
so 'import module' is to be preferred, right?
In C, it creates a problem called "name
space pollution". This is the case when a file1.c gets all the symbols
for some_header.h, even though it doesn't include/need those symbols,
because some header file1.c included needed a symbol from
some_header.h. This is especially galling if the pollution collides
with some_header2.h that file1.c actually needs.
<mike
thanks a lot, mike!
--
http://mail.python.org/mailman/listinfo/python-list