Huh, that's really weird. I use this technique all the time, and I never
worry about import order or having app-level values pre-set, and it always
works perfectly as expected for me.
$ cat settings.py
sound_volume = 1000
$ cat module.py
import settings
def printvolume():
print settings.sound_volume
$ cat main.py
import module, settings
module.printvolume()
settings.sound_volume = 3
module.printvolume()
$ python main.py
1000
3
Not sure what you're doing different from me, but it might be worth looking
into. There could be some other issue. Can you post a working example (like
I did) where it behaves different than you expect?
I also don't understand why you're testing android == True in your code.
That should never be the case. If the import is successful, android refers
to some module, not the value True.
-Christopher
On Fri, Dec 16, 2011 at 3:34 PM, Sean Wolfe <[email protected]> wrote:
> BTW guys, this is working for me. I'm using a module as an
> application-level variable store. In my top-level main.py, I'm setting
> variables that are referenced by modules down the line.
>
> I had to do a couple things to make it work. One, the app-level
> variables can't be already defined when imported, they have to be new
> values which are set after the import by main.py. Two, any subsequent
> modules which are imported have to import AFTER I'm done creating my
> "app variables".
>
> So it looks like this:
>
> -----
> main.py:
>
> import acolyte_settings
> try:
> import android
> except ImportError:
> android = False
> if android == True:
> acolyte_settings.ANDROID = True
> acolyte_settings.ASSETS_DIR = './assets'
>
> import gameloop
>
> def (main):
> gameloop.gameloop()
>
> Now gameloop can use the acolyte_settings module to find out the
> application settings. I don't have to write to an external file, or
> constantly pass 'android=True' to all my classes. It's not all that
> practical for multiple changes to the app-level variables, but for my
> purposers, I like it!
>
> Thanks for your help on this guys.
>
