[Tutor] Accessing variables from other modules

[Alan Gauld]

On 04/09/18 16:10, Chip Wachob wrote:

> (like I would do in C).  I then used the import statement to 'include'
> them into the main.py file.

OK a basically good idea but how did you use the import statement?
There are many forms:

import foo
from foo import name1, name2,...
from foo import *
import foo as f
from foo import name1 as n1


Now to access name1 (which could be a function,
class or global variable within foo) you could
do any of (depending on your import):

x = foo.name1
x = name1
x = name1
x = f.name1
x = n1

Does your import statememt and access method
match the above?

The other thing to remember is that local variables
(defined inside functions) are not visible outside
the function.

> I ran into a problem in that the code which was moved to the module
> could no longer 'see' the ft232h variable (object?).  After many
> attempts, I figured out that the best solution seemed to be to put the
> ft232h setup code into yet another file.  I then imported that file
> into both my main.py and foo.py files.  And, that seemed to work.. on
> Friday.

That may be a good idea, but it shouldn't really
have been necessary. And it should work any day
of the week :-)

> This morning, I came back to continue working on the code, and now the
> ft232h variable can no longer be 'seen' by my modules...

We need to see some actual code to figure that one out.

> When I was running the code on Friday it was being run from a command
> line each time.  So, I'm assuming that the dictionary disappears and
> that there is a new 'fresh' start each time I execute.  Is this
> correct?

Everything disappears at the end of the interpreter session,
so yes it starts afresh every time. (Unlike if you run your
modules from inside the interpreter in which case values
stick around.)

> main.py - calls various functions from other *.py files (foo.py, etc).
> It also creates a console-based menu selection which determines which
> of the functions to call.
> 
> foo.py (and others) - contain the actual functions for the different
> work that I want to get done.
> 
> spi.py - contains the setup and initialization code for the Adafruit
> board and configures it to function as a SPI peripheral via USB.

It is a good idea to keep the hardware specifics in one
place but for the purpose of this discussion it shouldn't
make any difference it's just another module.

> - Was I mislead by the fact that there was a power cycle on the
> machine and it has now forgotten something that was staying resident
> when I tested the code on Friday?  Or, does each 'run' of the script
> start fresh?

Each run should start afresh.
(The only caveat is that if there is some process still
running on your hardware(I don't know anything about the
board in question) it may retain memory and pass it back
to the init code in spi.py on startup. Does the board get
power cycled between runs?)

> - What approach do I need to use to be able to initialize the
> interface in spi.py and have it be something that is accessible to all
> the other modules in my project?

It depends a lot on your actual code. Without it
we are just guessing.


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos