redundant imports

[max(01)*]

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?

bye

macs

[Mike Meyer]

"max(01)*" <ma**@fisso.cas a> 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 "traditiona l" 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 <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Bengt Richter]

On Sat, 02 Apr 2005 16:44:29 -0600, Mike Meyer <mw*@mired.or g> wrote:

"max(01)*" <ma**@fisso.cas a> 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 "traditiona l" 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

Bzzt ;-) It's not the same semantics!import *" in python. Both cases add all the names in the included
namespace directly to the including namespace. This usage is But a C #include results in processing as if the _source_ were substituted
into the including source in place of the #include line. That's not what
from module import * does, because when import executes the module's source
(happening only the first time BTW, unlike in-place #include)
it creates a module global that is distinct from the includer's global.
The import * creates local bindings to the objects visible as bindings
in the global space of the module, but the objects retain their module
global references (if any, since there doesn't have to be any).

IMO execfile('modul e.py') is closer to C's #include effect. Note:

print '----\n%s----'%open('impex.p y').read() ----
g = 'g in global space of impex.py'
def showg(): print g

---- from impex import *
g 'g in global space of impex.py' showg() g in global space of impex.py g = 'g in global space of importer'
g 'g in global space of importer' showg() g in global space of impex.py

Note that showg insisted on looking for g in it's idea of global.
Now we'll bring in g and showg via execfile:
execfile('impex .py')
g 'g in global space of impex.py' showg() g in global space of impex.py g = 'g in global space of importer'
showg()

g in global space of importer

Note that because execfile executed the definition of showg in the
interactive global space, it sees the interactive change of g's binding
(in what it now also showg's global space).

(Execfile inside a function or class definition needs careful control, but can be done).
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.

Of course in C you could write some #ifxxx kludges to control inclusion of named things
from a given header file somewhat. But name space pollution is a pox, to be sure ;-)

Regards,
Bengt Richter

[Serge Orlov]

Mike Meyer wrote:

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 ...

Did you mean discouraged? Or it's really slated for deprecation?

Serge.

[Peter Hansen]

max(01)* wrote:

Peter Hansen wrote:

No it doesn't. I thought I was clear, but I can reword
it for you: the files are compiled *in-memory* and the
results are never written to disk.

> *if* they are compiled, where are they put, if the
corresponding *.py files are on a non-writeable directory?
They are not put anywhere.

ok, maybe it is an implementation-dependent issue after all.

Not really.
consider this: [snip] -rw-r--r-- 1 max2 max2 307 2005-04-02 17:45 imported.pyc

see?

Yes, but you don't, yet. :-)

Obviously the .pyc file is being written, so my comments
above, out of context, is wrong.

Now please go put them back in context. You asked what
would happen if the directory was not writable. That's
the context in which to interpret my claims that the
bytecode (the *result* of the compilation) is not
written to disk.

I'll try one last time, before giving up in abject
failure and letting someone else take a stab at this:
the compilation will occur every time if a .pyc file
does not exist. The interpreter will attempt to write
the results of the compilation process to disk in a
..pyc file to cache it for the next time, to avoid
having to recompile. *If* this is not possible, then
no caching takes place, no .pyc file is written, and
the next time you run the code, the compilation step
will occur all over again (note: with the results being
held in memory only while the program runs, then
discarded).

Please tell me it's clear now. :-)

-Peter

[Peter Hansen]

Serge Orlov wrote:

Mike Meyer wrote:

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 ...

Did you mean discouraged? Or it's really slated for deprecation?

Deprecated basically means "the use of this is discouraged",
though because it is often followed by a comment like
"and it will be removed in a future release", people
sometimes are misled into thinking "deprecate" refers
to the pending act of removal rather than the discouragement
itself.

So, yes, its use is deprecated (though I'm not sure if that's
by any official statement, or simply by widespread convention),
but no, that doesn't mean it is going to go away any time soon.

-Peter

[max(01)*]

Peter Hansen wrote:

max(01)* wrote:

Peter Hansen wrote:

No it doesn't. I thought I was clear, but I can reword
it for you: the files are compiled *in-memory* and the
results are never written to disk.

> *if* they are compiled, where are they put, if the

corresponding *.py files are on a non-writeable directory?
They are not put anywhere.

ok, maybe it is an implementation-dependent issue after all.

Not really.

consider this:

[snip]

-rw-r--r-- 1 max2 max2 307 2005-04-02 17:45 imported.pyc

see?

Yes, but you don't, yet. :-)

Obviously the .pyc file is being written, so my comments
above, out of context, is wrong.

oops!
Now please go put them back in context. You asked what
would happen if the directory was not writable. That's
the context in which to interpret my claims that the
bytecode (the *result* of the compilation) is not
written to disk.

I'll try one last time, before giving up in abject
failure and letting someone else take a stab at this:
the compilation will occur every time if a .pyc file
does not exist. The interpreter will attempt to write
the results of the compilation process to disk in a
..pyc file to cache it for the next time, to avoid
having to recompile. *If* this is not possible, then
no caching takes place, no .pyc file is written, and
the next time you run the code, the compilation step
will occur all over again (note: with the results being
held in memory only while the program runs, then
discarded).

Please tell me it's clear now. :-)

it's not clear. it's crystalline. :-)

thanks for your patience and help.

best regards

macs

[max(01)*]

Mike Meyer wrote:

"max(01)*" <ma**@fisso.cas a> 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
(compilatio n 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 "traditiona l" 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!