[Python-ideas] New PEP 550: Execution Context

[Yury Selivanov]

On Sat, Aug 12, 2017 at 10:12 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
[..]
>
> 1. Are you sure you want to expose the CoW type to pure Python code?

Ultimately, why not? The execution context object you get with
sys.get_execution_context() is yours to change. Any change to it won't
be propagated anywhere, unless you execute something in that context
with ExecutionContext.run or set it as a current one.

>
> The draft API looks fairly error prone to me, as I'm not sure of the
> intended differences in behaviour between the following:
>
>     @contextmanager
>     def context(x):
>         old_x = sys.get_execution_context_item('x')
>         sys.set_execution_context_item('x', x)
>         try:
>             yield
>         finally:
>             sys.set_execution_context_item('x', old_x)
>
>     @contextmanager
>     def context(x):
>         old_x = sys.get_execution_context().get('x')
>         sys.get_execution_context()['x'] = x
>         try:
>             yield
>         finally:
>             sys.get_execution_context()['x'] = old_x

This one (the second example) won't do anything.

>
>     @contextmanager
>     def context(x):
>         ec = sys.get_execution_context()
>         old_x = ec.get('x')
>         ec['x'] = x
>         try:
>             yield
>         finally:
>             ec['x'] = old_x

This one (the third one) won't do anything either.

You can do this:

    ec = sys.get_execution_context()
    ec['x'] = x
    ec.run(my_function)

    or `sys.set_execution_context(ec)`


>
> It seems to me that everything would be a lot safer if the *only*
> Python level API was a live dynamic view that completely hid the
> copy-on-write behaviour behind an "ExecutionContextProxy" type, such
> that the last two examples were functionally equivalent to each other
> and to the current PEP's get/set functions (rendering the latter
> redundant, and allowing it to be dropped from the PEP).

So there's no copy-on-write exposed to Python actually. What I am
thinking about, though, is that we might not need the
sys.set_execution_context() function. If you want to run something
with a modified or empty execution context, do it through
ExecutionContext.run method.

> 2. Do we need an ag_isolated_execution_context for asynchronous
> generators? (Modify this question as needed for the answer to the next
> question)

Yes, we'll need it for contextlib.asynccontextmanager at least.

>
> 3. It bothers me that *_execution_context points to an actual
> execution context, while *_isolated_execution_context is a boolean.
> With names that similar I'd expect them to point to the same kind of
> object.

I think we touched upon this in a parallel thread. But I think we can
rename "gi_isolated_execution_context" to
"gi_execution_context_isolated" or something more readable/obvious.

Yury