On Wed, Apr 29, 2015 at 2:01 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
Sorry for not replying to your last email promptly. FWIW I was going to do it later today ;)
My opinion on this subject (and I've implemented lots of local-context kind of objects in different frameworks) is that *just* inserting some kind of suspend/resume points before/after yields does not work.
Very good observation. (I.e. I hadn't thought of this myself. :-)
Why:
1. Greenlets, gevent, eventlet, stackless python: they do not have 'yield'. Context switches are invisible to the interpreter. And those frameworks are popular. You want numpy.errstate/decimal.localcontext to work there too.
2. I'm curious how this will be implemented and what's the performance impact.
3. I think that mechanism should be more generic than just 'with' staments. What if you want to have a decorator that applies some context? What if you can't write it as a generator with @contextlib.contextmanager?
What I would propose:
I think that the right approach here would be to have a standard protocol; something similar to how we defined WSGI -- it doesn't require any changes in the interpreter, it is a protocol.
For instance, we could have a module in the stdlib, with a class Context:
class Context: @classmethod def __suspend_contexts(cls): for child in cls.__subclasses__(): child.__suspend_context()
@classmethod def __resume_contexts(cls): ..
To inform context objects that the context is about to change, asyncio event loop would call Context.__suspend_contexts()
I think that it's up to the event loop/library/framework to manage context switches properly. In asyncio, for instance, you can attach callbacks to Futures. I think it would be great if such callbacks are executed in the right context.
I'm not sure about this, since currently those callbacks are how task scheduling happens. :-)
I would also suggest to think about a universal context -- the one that works both for asyncio coroutines and threadpools they might use.
This way any framework can implement the context in the most efficient way.
All in all, I'm in favor of API and a couple functions added to the stdlib for this.
I'm curious -- how would you access the current contexts? -- --Guido van Rossum (python.org/~guido)