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

Reply via email to