[Python-Dev] Timeout for PEP 550 (original) (raw)

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

Guido van Rossum guido at python.org
Wed Oct 18 14:21:34 EDT 2017

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 'setctx()' 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 'setctx' 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 'setctx' 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>

More information about the Python-Dev mailing list