Discussion: Allow push_scope to act as a decorator?

[a-d-collins]

In some scenarios it is desirable to have a specific scope attached to every call of a given method. Instead of pushing a scope in every caller of that method it could make more sense to decorate the method with a pushed scope and then modify that temporary scope at the top of the method (or even assign the scope attributes in the decorator call).

As found in #523, bootstrapping the current push_scope API with decorator functionality is not simple. It seems that some amount of API-breakage is necessary in order allow push_scope to work as a decorator. Due to this, it's a good idea to discuss the intentions of and use cases for push_scope.

[untitaker]

So if you have this flask app:

@push_scope_decorator
def foo_core_logic(a, b):
    with configure_scope():
        ...

    return a / b

@app.route("/foo/<a:int>/<b:int>")
def foo(a, b):
    return str(foo_core_logic(a, b))

and use the Flask integration, you will get a ZeroDivisionError on /foo/1/0.

However, the scope data will not be attached, because the exception bubbles up from foo_core_logic and the scope will be popped.

This is why a push_scope() only makes sense with local exception handling.

BTW we tried to generically change the behavior of push_scope to somehow keep the scope around when an exception is being raised, but the PoC seemed dangerously leaky.