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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
