If they are constants, IMO globals are ok.
If you have to run some code to generate the values, I would define methods (and possibly put them in another module if they are to be reused) that I can call from my_function. Actually, even for constants you could abstract them with a simple function.
def foo():
# compute and return value
def bar():
# compute and return value
def my_function():
baz = foo() + bar()
Also, the application context in flask might be of some use for you if you want to cache resources like database connections for example
Edit after reading the comments on the original question
You should probably really use a key-value store, maybe consider flask-session as well:
https://pythonhosted.org/Flask-Session/
Otherwise you'll get not only multithreaded problems (can be fixed with using a lock), but also multiprocess problems as soon as you run two worker processes -- one request might save data in 1 process, but the next request can land on a different one.
If you really want to do this only for prototyping, I'd suggest you at least abstract the access to the user data instead of exposing the raw dictionary. One simple ways is something like this:
class FooStore(object):
FOO = {}
@classmethod
def get(cls, user_id):
return FOO.get(user_id)
@classmethod
def set(cls, user_id, value):
return cls.FOO[user_id] = value
# Access/set the values
FooStore.set(1, {'data': 'some user data'})
FooStore.get(1)
Later you will be able to easily change the implementations of set
and get
. For example serialize and store to Redis and fetch and deserialize from Redis, respectively. It will also allow for easier testing.