On 16 August 2017 at 17:18, Nathaniel Smith <n...@pobox.com> wrote: [Yury wrote] >> For these purposes we add a set of new APIs (they will be used in >> later sections of this specification): >> >> * ``sys.new_local_context()``: create an empty ``LocalContext`` >> object. >> >> * ``sys.new_execution_context()``: create an empty >> ``ExecutionContext`` object. >> >> * Both ``LocalContext`` and ``ExecutionContext`` objects are opaque >> to Python code, and there are no APIs to modify them. >> >> * ``sys.get_execution_context()`` function. The function returns a >> copy of the current EC: an ``ExecutionContext`` instance. > > If there are enough of these functions then it might make sense to > stick them in their own module instead of adding more stuff to sys. I > guess worrying about that can wait until the API details are more firm > though.
I'm actually wondering if it may be worth defining a _contextlib module (to export the interpreter level APIs to Python code), and making contextlib the official home of the user facing API. That we we can use contextlib2 to at least attempt to polyfill the coroutine parts of the proposal for 3.5+, even if the implicit generator changes are restricted to 3.7+ . >> * If ``coro.cr_local_context`` is an empty ``LocalContext`` object >> that ``coro`` was created with, the interpreter will set >> ``coro.cr_local_context`` to ``None``. > > I like all the ideas in this section, but this specific point feels a > bit weird. Coroutine objects need a second hidden field somewhere to > keep track of whether the object they end up with is the same one they > were created with? It feels odd to me as well, and I'm wondering if we can actually simplify this by saying: 1. Generator contexts (both sync and async) are isolated by default (__local_context__ = LocalContext()) 2. Coroutine contexts are *not* isolated by default (__local_context__ = None) Running top level task coroutines in separate execution contexts then becomes the responsibility of the event loop, which the PEP already lists as a required change in 3rd party libraries to get this all to work properly. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
