Basic importing question

[Hussein B]

Hey,
Suppose I have a Python application consists of many modules (lets say
it is a Django application).
If all the modules files are importing sys module, how many times the
sys module will be compiled and executed?
Only once (the first time the PVM locates, compiles and executes the
sys module)? or once for each module importing sys?
Thanks.

[Bruno Desthuilliers]

Hussein B a écrit :

Hey,
Suppose I have a Python application consists of many modules (lets say
it is a Django application).
If all the modules files are importing sys module, how many times the
sys module will be compiled and executed?
Only once (the first time the PVM locates, compiles and executes the
sys module)? or once for each module importing sys?

Hmmm.... Well, could it be possible that Python's developper were smart
enough to implement some cache mechanism here ?-)

import do (approximately) the following:

check if the module already exists in sys.modules
if not:
locate the module's source in sys.path
if not found
raise an import error
look for a compiled .py file
if there's none, or if there's one and it's older than the .py file:
compile the source and save it as .pyc
execute the .pyc file and build a module object from it
add the module object to sys.modules
bind the relevant names into your current namespace

[John Machin]

On Aug 20, 8:08*pm, Hussein B <[e-mail]:

Hey,
Suppose I have a Python application consists of many modules (lets say
it is a Django application).
If all the modules files are importing sys module, how many times the
sys module will be compiled and executed?
Only once (the first time the PVM locates, compiles and executes the
sys module)? or once for each module importing sys?
Thanks.

sys is a built-in module, so the answer is zero times.

For a non-builtin module foo where there exists:
(1) only a foo.py, it will be compiled into foo.pyc
(2) only a foo.pyc, it will be used
(3) both a foo.py and a foo.pyc, Python compiles the foo.py if the pyc
is out of date or (so I believe[*]) was created by a different
version of Python.

Subsequent imports will use the in-memory copy (in sys.modules, IIRC[*]) ...
[*] == Please save me the bother of checking this in the manual :-)

HTH,
John

[Hussein B]

On Aug 20, 5:43 am, John Machin <[e-mail]:

On Aug 20, 8:08 pm, Hussein B <[e-mail]:

Hey,
Suppose I have a Python application consists of many modules (lets say
it is a Django application).
If all the modules files are importing sys module, how many times the
sys module will be compiled and executed?
Only once (the first time the PVM locates, compiles and executes the
sys module)? or once for each module importing sys?
Thanks.

sys is a built-in module, so the answer is zero times.

For a non-builtin module foo where there exists:
(1) only a foo.py, it will be compiled into foo.pyc
(2) only a foo.pyc, it will be used
(3) both a foo.py and a foo.pyc, Python compiles the foo.py if the pyc
is out of date or (so I believe[*]) was created by a different
version of Python.

Subsequent imports will use the in-memory copy (in sys.modules, IIRC[*]) ...
[*] == Please save me the bother of checking this in the manual :-)

HTH,
John

One more question:
If I have this structure:
orig/com/domain/project/Klass1.py
Klass2.py
__init__.py

Why com, domain, project should have __init__.py also? they don't
contain source code files?
Thanks again.

[Bruno Desthuilliers]

Hussein B a écrit :
(snip)

One more question:
If I have this structure:
orig/com/domain/project/Klass1.py
Klass2.py
__init__.py

Why com, domain, project should have __init__.py also?

Yes, why should they ? Unless you want to mimic Java's package system so
you do "import com.domain.project.stuff" - which is IMHO a pretty bad
idea -, there's just no reason to turn all your filesystem into a python
package.

Python's philosophy here is that flat is better than nested.

[Hussein B]

On Aug 20, 6:39 am, Bruno Desthuilliers <bruno.
[e-mail]:

Hussein B a écrit :
(snip)

One more question:
If I have this structure:
orig/com/domain/project/Klass1.py
Klass2.py
__init__.py

Why com, domain, project should have __init__.py also?

Yes, why should they ? Unless you want to mimic Java's package system so
you do "import com.domain.project.stuff" - which is IMHO a pretty bad
idea -, there's just no reason to turn all your filesystem into a python
package.

Python's philosophy here is that flat is better than nested.

Sorry I don't follow you :(
Module package is also nested.

[Scott David Daniels]

Hussein B wrote:

On Aug 20, 6:39 am, Bruno Desthuilliers <bruno.
[e-mail]:

>Hussein B a écrit :

>>One more question:
If I have this structure:
orig/com/domain/project/Klass1.py
Klass2.py
__init__.py
Why com, domain, project should have __init__.py also?

Yes, why should they ? Unless you want to mimic Java's package system so
you do "import com.domain.project.stuff" - which is IMHO a pretty bad
idea -, there's just no reason to turn all your filesystem into a python
package.

Python's philosophy here is that flat is better than nested.

Sorry I don't follow you :(
Module package is also nested.

Essentially, "flatter is better than more nested" -- in other words
the things you see after "import this" are principles to trend towards,
not commandments to never be violated. Some structure is better
than no structure, but that doesn't mean more structure is better
ad infinitum. Lists of length 1, modules containing a single class,
dictionaries with a single entry, functions or methods that simply
return a variable or instance are "code smells" for over-exercise of
structuring for its own sake. Each layer should have enough structure
that it is "worth" replacing the more straightforward access with a
name.
Similarly, the name should be associated with few enough things
that you might reasonably expect to hold its scope in your head.
A layer with fifty elements "smells" as bad as one with a single
element, just in a different way.

--Scott David Daniels
Sc***********@Acm.Org

[Christian Heimes]

Bruno Desthuilliers wrote:

As the name imply, built-in modules are built in the interpreter - IOW,
they are part of the interpreter *exposed* as modules[1]. Unless you
have a taste for gory implementation details, just don't worry about this.

Other "ordinary" modules need of course to be executed once when first
loaded - IOW, the first time they are imported. All statements[2] at the
top-level of the module are then sequentially executed, so that any
relevant object (functions, classes, whatever) are created and bound in
the module's namespace.

Builtin modules like thread, signal etc. as well as C extensions like
socket have an initialization function. The initialization function is
called during the first import of a module. It creates the module object
and assigns objects to its __dict__ attribute.

Builtin modules are statically linked into the Python executable /
library while normal C extensions are shared libraries. Some modules are
builtins because they are required during boot strapping. It's possible
to embed most C modules into the core.

Christian