On Sat, Aug 12, 2017 at 10:12 AM, Nick Coghlan <ncogh...@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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
