[Python-Dev] Timeout for PEP 550 / Execution Context discussion

[Guido van Rossum]

On Wed, Oct 18, 2017 at 10:50 AM, Yury Selivanov <yselivanov.ml at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171018/bb1fb6c9/attachment.html>