Hi Nathanial, 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. 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 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. Thanks, Yury On 2015-04-29 4:22 PM, Nathaniel Smith wrote:
Hi all,
Well, after a few days no-one has responded to my post on another thread about this [1], but the more I thought about it the more this seemed like a good idea, so I wrote up a little more-formal proposal (attached) for letting context managers react to 'yield's that occur within their 'with' block.
This should in many ways be treated as a straw man proposal -- there's tons I don't know about how async code is written in Python these days -- but it seems like a good idea to me and I'd like to hear what everyone else thinks :-).
-n
[1] https://mail.python.org/pipermail/python-ideas/2015-April/033176.html
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/