1

Is it better to store state in a global variable or in a coroutine, specifically in Python? I don't understand the best practice here.

For example, consider a simple Flask script:

from flask import Flask
...

app = Flask(__name__)

### GLOBAL MEMORY ############ OPTION 1

exmple_variable = 'contents of some file or something.'

### COROUTINE ############### OPTION 2

def get_example_variable():
    a = yield
    while True:
        yield a

exmple_variable_coroutine = get_example_variable()
next(exmple_variable_coroutine)
exmple_variable_coroutine.send('contents of some file or something.')

### PAGES ####################

@app.route('/')        # uses option 1
def page_home():
    return render_template('index.html', example=example_variable)

@app.route('/index')   # uses option 2
def page_index():
    return render_template('index.html', example=next(exmple_variable_coroutine))

if __name__ == '__main__':
    app.run()

So there you have a short Flask app with the two options outlined. In a case like this, would it be better practice to use the coroutine or to use the global variable?

The variable representing the hook to the coroutine exmple_variable_coroutine is essentially a global variable itself. So I'm not sure if all that added complexity helps much. As this project grows, perhaps there's some value added, but I don't know what it would be.

2
  • 3
    Global variables in "short scripts" are fine. It's when "short scripts" turn into "bigger programs" they begin to become trouble. – whatsisname Jun 29 '18 at 0:37
  • Aside from implementing classes and OOP completely what solutions would you suggest? – Legit Stack Jun 29 '18 at 3:00
1

Your coroutine implements a read-only global variable but with extra steps. I don't see how it has any value compared to simply using a global variable directly (especially considering that the variable holding the coroutine is also a global variable). The coroutine approach is arguably worse because the coroutine state could change, whereas a global constant … well, stays constant.

It's not shared global data that's a problem, but shared state. Here, “state” is any data that changes over time. For a web application, any shared state belongs into a database or similar persistence mechanism. But it's perfectly fine to load read-only data at startup, and to store that data in a global variable.

Python style guides encourage that any top-level variables should be constants, and should use ALL_UPPERCASE to indicate this. Python can't actually enforce that you don't reassign a global variable, but it's unlikely to happen accidentally.

So in summary, if you need keep data around for the whole lifetime of your app, then a global constant is vastly preferable compared to this unusual coroutine construction.

1

I'd say the bigger issue with global variable is the mutable global state itself. If any dependency of a function reads or writes the global state it effectively becomes a hidden interface of the function, which should be considered when you use it. So it does not matter much how do you prettify and hide them. It can be a global variable, or module local variable with getter and setter, or even module local variable which is used internally.

Actually, in your "courotine" example, the state is not global, it is tied to the variable exmple_variable_coroutine, if you don't make it global but create only inside function then your state is not global

0

From my exp, global values are always to be avoided, especially in large programs. They're convenient short term, but down the road they can cause conflicts, maintenance issues, possibly bugs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.