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/