Importing modules

[qwweeeit]

The pythonic way of programming requires, as far as I know, to spread a
big application in plenty of more manageable scripts, using import or
from ... import to connect the various modules.
In some cases there is a further complication: module importing through
an indirect mechanism, like: exec "from " + xxx + " import *".

A part the fact that I have not understood the "real" difference
between import and from ... import (or also from... import *), is it
possible to re-build the application in only one chunck?
This is only to better understand the application's structure, in order
to implement a flow chart tool.

I have already developed a cross reference tool and I applied it to
PySol (solitary card games). PySol is made up of almost 100 modules for
a total of almost 30000 lines.
To understand a program, however, you need also a flow chart...

 

[Fredrik Lundh]

To understand a program, however, you need also a flow chart...

so understand a carefully designed modular component structure, you
have to remove the structure so you can create a flow chart?

did you perhaps stumble upon a strange man with a keg of liquor back
in the sixties, or what's going on here? ;-)

</F>

 

[=?iso-8859-1?q?S=E9bastien_Boisg=E9rault?=]

(e-mail address removed) wrote:
[...]

In some cases there is a further complication: module importing through
an indirect mechanism, like: exec "from " + xxx + " import *".

Don't do that. Please . If you need too import some modules based
on the module name, stored in a string, consider the using __import__
(http://www.python.org/doc/2.4/lib/built-in-funcs.html). It's a bit
tricky but you may define your own help functions on top of it.

A part the fact that I have not understood the "real" difference
between import and from ... import (or also from... import *),

is it
possible to re-build the application in only one chunck?
This is only to better understand the application's structure, in order
to implement a flow chart tool.

uh ?

 

[George Sakkis]

:

so understand a carefully designed modular component structure, you
have to remove the structure so you can create a flow chart?

did you perhaps stumble upon a strange man with a keg of liquor back
in the sixties, or what's going on here? ;-)

</F>

In more modern terminology, an analog might be UML sequence diagrams.

George

 

[qwweeeit]

Fredrik Lundh ha scritto:

so understand a carefully designed modular component structure, you
have to remove the structure so you can create a flow chart?

Not everyone is a "guru" like you... I already implemented (some years
ago) flow chart tools but for structured languages, not Object Oriented
ones like Python.
So forgive me if I'm in trouble... Instead of mocking me, the better
should be to give me an brief idea of the import's roll (namespaces,
visibility and so on...)

Bye.

 

[Steve Holden]

Fredrik Lundh ha scritto:



Not everyone is a "guru" like you... I already implemented (some years
ago) flow chart tools but for structured languages, not Object Oriented
ones like Python.
So forgive me if I'm in trouble... Instead of mocking me, the better
should be to give me an brief idea of the import's roll (namespaces,
visibility and so on...)

Bye.

Please forgive the effbot, which has been in need of lubrication for
some time. I am happy to say that he will be offline for three minutes
and forty-six seconds tomorrow at 0945 UTC, after which we expect that
advice will be dispensed in a rather more dispassionate fashion.
According to the research team an effort to engender empathy in the
bot's behavior and thus make it more acceptable to a majority of the
Python community was found to conflict with the "can't teach an old dog
new tricks" circuitry that inherently limits the expansion capability of
all the early generation bots.

In round terms you might say that

import module

brings the named module into the current name space as a dependent name
space. Since the module is accessible by its name (in this case
"module"), names defined inside the module (normally, remember, only
executed once the first time it is imported) are available from the
importing module by qualifying the name of the desired value with the
name of the imported module. Hence

module.func(2, 3, 4)

calls the function func defined in module with three numeric arguments.

name = module.a

binds the name "name" in the local namespace to the same value currently
referenced by the name "a" in "module".

On the other hand,

from module import func, a

takes the names "func" and "a" bound (we hope) when the module was
executed on first import and binds the same names to the same values in
the current (importing) module's name space.

The usual (Python) rules for binding apply: when several names are bound
to the same mutable value all bindings reference the same object, and a
change to the referenced mutable object is seen no matter which binding
is used to access that value.

Rebinding of a name from an immutable value means it no longer
references the same object it formerly did.

regards
Steve

 

[Mike Meyer]

A part the fact that I have not understood the "real" difference
between import and from ... import (or also from... import *), is it
possible to re-build the application in only one chunck?
This is only to better understand the application's structure, in order
to implement a flow chart tool.

"import foo" creates foo in the current namespace. It'll be a module.

"from foo import bar" creates bar from the foo module in the current
namespace. It's type will be the same as it is in foo. Note that
assigning to bar in the current namespace after doing this import
*will not* change bar in foo.

I have already developed a cross reference tool and I applied it to
PySol (solitary card games). PySol is made up of almost 100 modules for
a total of almost 30000 lines.
To understand a program, however, you need also a flow chart...

*You* may need a flowchart. Lots of people don't. The last time I had
to document a program graphically, I used something other than
flowcharts (I've since forgotten the name, but could provide examples
on demand). Such tools are really only useful for describing a single
function. To understand the relationship between
functions/methods/etc., you really need other tools. UML is probably
the most used such tool in the OO world.

To understand a program, you need to understand the communications
channels between the components. Mashing all the components together
into one namespace destroys the very information you need to properly
understand the program. BON is a nice format for documenting such
things, but it's really aimed at a more pure OO environment than
Python provides.

<mike

 

[qwweeeit]

Hi all.

... to conflict with the "can't teach an old dog new tricks" ...

Excuse my English (also some terms of your replay have no
correspondance in my English dictionary...) and my lack of patience
(beeing an "old dog" ...).

My original request was mainly centered on flow chart and "import"
interfered with "my" understanding of an application.

By the way, (replaying to Sébastien Boisgérault) of course I don't
use indirect import of any sort (it's too tricky for me...).

The only constructive comments was that of George Sakkis on using UML
sequence diagrams.
Also Mike Meyer points me in the same direction (with more arguments
and ... warnings).

I will stick with their advice: I will abandon my project of
implementing a flow chart tool...

A last word of reconciliation: I must thank the expert group for their
valuable activity especially towards the newbies like me...

Regards.

 

[Fredrik Lundh]

So forgive me if I'm in trouble... Instead of mocking me, the better
should be to give me an brief idea of the import's roll (namespaces,
visibility and so on...)

if you're interested in learning stuff, why not spend your time reading
up on how things work, rather than bragging about how you won't use
classes, etc, and posting silly assertions.

there are plenty of information on python.org; if you get stuck on some
specific part of it, there are lots of people here than can help you sort
things out. but if you don't even want to try, all you're doing is wasting
time -- your own, and others.

</F>

 

[qwweeeit]

Hi Fredrik,
thank you for saying that I am

... posting silly assertions.

I didn't born " Python expert", and I am hardly trying to learn
something.
I don't like classes but this assertion (silly... I agree) is due to
the fact that "I don't understand them well" (I hope to change mind in
a near future).
Another item (for me...) difficult, is "import modules", and "plenty of
information" (as you said) does not help me much: the mechanism of
variable visibility and namespaces is not clear to me. It will be
enough an example of the various type of imports and they difference in
terms of namespaces or, better, of something you can see on your
monitor, or print like, for example, a dictionary.
As you can see from my replay to Steve Holden, I have abandoned my
project on flowcharting. I must study (as you adviced me)...
Bye.

 

[Fredrik Lundh]

Another item (for me...) difficult, is "import modules", and "plenty of
information" (as you said) does not help me much: the mechanism of
variable visibility and namespaces is not clear to me.

have you read this

http://effbot.org/zone/python-objects.htm

and

http://effbot.org/zone/import-confusion.htm

?

</F>

 

[qwweeeit]

Hi Fredrik,
thank you very much for your articles (especially that on
import-confusion). At last I grasped, also if not thorougly, the import
mechanism. What cleared my doubts was your recursive import paragraph.
In the Guido's "Python Reference Manual" he says:
"Import statements are executed in two steps: (1) find a module , and
initialize it if necessary..."
....almost like it was not necessary to go through it executing it (and
initializing the classes if necessary).
I made a small script to be sure and (...of course) confirmed what you
said...
I have still some doubts on the namespaces and functions/variables
visibility, but for that there is the error mechanism...
Bye.

 

[jmdeschamps]

CONTEXT:
Trying to modularize (is this english?) application development : MVC
style, team distributed so that a visual component can be in one module
imported and used by the __main__, and connected (read packed) at
runtime to other components coming from the main or other modules.

PROBLEM:
After reading the above reference (and the Nutshell chapter) and trying
different importing variations I still have a very difficult time
understanding this situation.
1-importing Tkinter in main,
2-importing module that uses Tkinter, without importing Tkinter in that
module (DOES NOT WORK)
KLUDGED SOLUTION:
import Tkinter in module (but don't understand why it has to be this
way)

MODEL (I taught would work):
## importTestMain module
from Tkinter import *
import testModule

tata = testModule.toto() ## this works
myWidget = tata.createNewFrame() ## this gets the exception (see below)
....

## testModule
class toto(object):
def __init__(self):
self.someAttribute= 2
def createNewFrame(self):
self.myFrame = Frame() ## culprit line in exception
return f

if __main__=='__name__': ## team member tests is work here (does
work!)
from Tkinter import *
myInstance = otherModule.toto()
myWidget = myInstance.createNewFrame()
root=Tk()
myWidget.pack(in_=root)
root.mainloop()

The exception says :
Traceback (most recent call last):
File
"C:\Python23\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py",
line 310, in RunScript
exec codeObject in __main__.__dict__
File
"C:\jean_marc\exemples_code_source\modules_packages\import_test\importTestMain.py",
line 18, in ?
tata=toto()
File
"C:\jean_marc\exemples_code_source\modules_packages\import_test\importTestMain.py",
line 10, in __init__
self.myNewFrame =
self.myTestModuleObject.createNewFrame(self.myInterModuleTestCommand)
File
"C:\jean_marc\exemples_code_source\modules_packages\import_test\testModule.py",
line 8, in createNewFrame
self.myFrame = Frame()
NameError: global name 'Frame' is not defined
VARIATION
Imported testModule AFTER using Tkinter in main... same error