redundant imports

[Mike Meyer]

"max(01)*" <max2 at fisso.casa> 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>.

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. 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
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.