«

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

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>

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 ?

"Fredrik Lundh" wrote :

> 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

Fredrik Lundh ha scritto:
> 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.

wrote:
> Fredrik Lundh ha scritto:
>
>> 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/

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 <> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

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.

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>

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.