Re: redundant imports
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.. 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. thanks a lot, mike! -- http://mail.python.org/mailman/listinfo/python-list
Re: redundant imports
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: redundant imports
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: redundant imports
On Sat, 02 Apr 2005 16:44:29 -0600, Mike Meyer <[EMAIL PROTECTED]> 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..
>
>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('module.py') is closer to C's #include effect. Note:
>>> print '\n%s'%open('impex.py').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
--
http://mail.python.org/mailman/listinfo/python-list
Re: redundant imports
"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.. 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. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: redundant imports
Peter Hansen wrote: max(01)* wrote: this leads me to another question. since *.pyc files are automatically created the first time an import statement in executed on a given module, i guess that if i ship a program with modules for use in a directory where the user has no write privileges then i must ship the *.pyc files along too. right? Not required except for performance reasons. If the .pyc files don't exist, the .py files are recompiled and the resulting bytecode is simply held in memory and not cached and the next startup will recompile all over again. Note also that the main file (the one invoke from the command line) is never cached in a .pyc... but the other files *are* compiled, right? so the initial question remains unanswered: *if* they are compiled, where are they put, if the corresponding *.py files are on a non-writeable directory? -- http://mail.python.org/mailman/listinfo/python-list
Re: redundant imports
Peter Hansen wrote: max(01)* wrote: this leads me to another question. since *.pyc files are automatically created the first time an import statement in executed on a given module, i guess that if i ship a program with modules for use in a directory where the user has no write privileges then i must ship the *.pyc files along too. right? Not required except for performance reasons. If the .pyc files don't exist, the .py files are recompiled and the resulting bytecode is simply held in memory and not cached and the next startup will recompile all over again. Note also that the main file (the one invoke from the command line) is never cached in a .pyc... -Peter Also, beware that you ship the right .pyc files - they are version-dependent, so shipping 2.3 binaries to a 2.4 user will actually cause a small slow-down, since the interpreter will have to check the .pyc's for the correct magic number before ignoring them. regards Steve -- Steve Holden+1 703 861 4237 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: redundant imports
max(01)* wrote: this leads me to another question. since *.pyc files are automatically created the first time an import statement in executed on a given module, i guess that if i ship a program with modules for use in a directory where the user has no write privileges then i must ship the *.pyc files along too. right? Not required except for performance reasons. If the .pyc files don't exist, the .py files are recompiled and the resulting bytecode is simply held in memory and not cached and the next startup will recompile all over again. Note also that the main file (the one invoke from the command line) is never cached in a .pyc... -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: redundant imports
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. You say first that "[code-1] uses names from both", which by definition means that it needs to import both. (I say by definition because import is *how* a module gets names from another module.) Then you say that code-1 can choose not to include code-3 because some other module is including it... but so what? That doesn't change the fact that code-1 needs names from code-3, and just because code-3 is imported elsewhere is no reason to think that code-1 magically gets its names too. Should all modules magically see all names in all modules which are imported, even by other modules? that's how inclusion works in c, which is why i asked for clarification about the differences between c-style includes and python-style imports. now i can see that python-style import is more like the inclusion of declarations in c (the "names"), usually shipped as *.h header files. the real *definition* of names is python (contents of variables, definition of functions, and so on) i guess is inserted later in the process of execution. That would pretty much defeat most of the value of namespaces. Anyway, why this concern over so-called redundant imports? The source code itself is not parsed and compiled all over again, and even the .pyc file is not re-read... once any module has imported a module any other import just retrieves a reference to that module from the sys.modules dictionary, which is practically a free operation. -Peter 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. thanks again for your couseling. bye macs -- http://mail.python.org/mailman/listinfo/python-list
Re: redundant imports
Tim Jarman 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? bye macs It's not as redundant as it looks. that's why i used quotes ;-) Once a module has been imported it goes into sys.modules and any subsequent imports refer to that original import, so the overhead of reading and parsing the file is only incurred once. As you're probably aware, Python also caches compilation results in *.pyc files; it will only compile the imported module if it changed since the last compilation. this leads me to another question. since *.pyc files are automatically created the first time an import statement in executed on a given module, i guess that if i ship a program with modules for use in a directory where the user has no write privileges then i must ship the *.pyc files along too. right? Check out the docs for the full skinny, in particular http://www.python.org/doc/2.4/ref/import.html HTH, Tim J thanks a lot bye macs -- http://mail.python.org/mailman/listinfo/python-list
Re: redundant imports
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. You say first that "[code-1] uses names from both", which by definition means that it needs to import both. (I say by definition because import is *how* a module gets names from another module.) Then you say that code-1 can choose not to include code-3 because some other module is including it... but so what? That doesn't change the fact that code-1 needs names from code-3, and just because code-3 is imported elsewhere is no reason to think that code-1 magically gets its names too. Should all modules magically see all names in all modules which are imported, even by other modules? That would pretty much defeat most of the value of namespaces. Anyway, why this concern over so-called redundant imports? The source code itself is not parsed and compiled all over again, and even the .pyc file is not re-read... once any module has imported a module any other import just retrieves a reference to that module from the sys.modules dictionary, which is practically a free operation. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: redundant imports
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? > > bye > > macs It's not as redundant as it looks. Once a module has been imported it goes into sys.modules and any subsequent imports refer to that original import, so the overhead of reading and parsing the file is only incurred once. As you're probably aware, Python also caches compilation results in *.pyc files; it will only compile the imported module if it changed since the last compilation. Check out the docs for the full skinny, in particular http://www.python.org/doc/2.4/ref/import.html HTH, Tim J -- Website: www DOT jarmania FULLSTOP com -- http://mail.python.org/mailman/listinfo/python-list
redundant imports
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 -- http://mail.python.org/mailman/listinfo/python-list
