By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,340 Members | 1,373 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,340 IT Pros & Developers. It's quick & easy.

Importing modules

P: n/a
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...

Jul 19 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
qw******@yahoo.it wrote:
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>

Jul 19 '05 #2

P: n/a

qwwee...@yahoo.it 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 *),
a = exp(1.0) # does not work import math
e = math.exp(1.0)# works
e = exp(1.0) # does not work from math import exp
e = exp(1.0) # works from math import *
e = exp(1.0) # works
o = sqrt(1.0) # works too

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 ?

Jul 19 '05 #3

P: n/a
"Fredrik Lundh" wrote :
qw******@yahoo.it wrote:
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>


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

George

Jul 19 '05 #4

P: n/a

Fredrik Lundh ha scritto:
qw******@yahoo.it wrote:
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?


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.

Jul 19 '05 #5

P: n/a
qw******@yahoo.it wrote:
Fredrik Lundh ha scritto:
qw******@yahoo.it wrote:

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?

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
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

Jul 19 '05 #6

P: n/a
qw******@yahoo.it writes:
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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jul 19 '05 #7

P: n/a
Hi all.

Steve Holden wrote:

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

Jul 19 '05 #8

P: n/a
qw******@yahoo.it wrote:
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>

Jul 19 '05 #9

P: n/a
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.

Jul 19 '05 #10

P: n/a
qw******@yahoo.it wrote:
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>

Jul 19 '05 #11

P: n/a
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.

Jul 19 '05 #12

P: n/a
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_package s\import_test\importTestMain.py",
line 18, in ?
tata=toto()
File
"C:\jean_marc\exemples_code_source\modules_package s\import_test\importTestMain.py",
line 10, in __init__
self.myNewFrame =
self.myTestModuleObject.createNewFrame(self.myInte rModuleTestCommand)
File
"C:\jean_marc\exemples_code_source\modules_package s\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 :(

Jul 19 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.