On Wed, Oct 18, 2017 at 10:50 AM, Yury Selivanov <yselivanov...@gmail.com> wrote:
> The main reason why I don't like 'set_ctx()' is because it would make > it harder for us to adopt PEP 550-like design later in the future > (*if* we need that.) > > PEP 550 is designed in such a way, that 'generator.send()' is the only > thing that can control the actual stack of LCs. If users can call > 'set_ctx' themselves, it means that it's no longer safe for > 'generator.send()' to simply pop the topmost LC from the stack. This > can be worked around, potentially, but the we don't actually need > 'set_ctx' in asyncio or in any other async framework. There is simply > no hard motivation to have it. That's why I'd like to have just > Context.run(), because it's sufficient, and it doesn't burn the bridge > to PEP 550-like design. > Honestly that stack-popping in send() always felt fragile to me, so I'd be happy if we didn't need to depend on it. That said I'm okay with presenting set_ctx() *primarily* as an educational tool for showing how Context.run() works. We could name it _set_ctx() and add a similar note as we have for sys._getframe(), basically keeping the door open for future changes that may render it non-functional without worries about backward compatibility (and without invoking the notion of "provisional" API). There's no problem with get_ctx() right? -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
