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

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

Yury Selivanov yselivanov.ml at gmail.com
Wed Oct 18 14:45:38 EDT 2017

On Wed, Oct 18, 2017 at 2:21 PM, Guido van Rossum <guido at python.org> wrote:

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 setctx() primarily as an educational tool for showing how Context.run() works. We could name it setctx() 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).

'_set_ctx()' + documentation bits work for me. I also assume that if you accept the PEP, you do it provisionally, right? That should make it possible for us to slightly tweak the implementation/API/semantics in 3.8 if needed.

There's no problem with getctx() right?

Yes, 'get_ctx()' is absolutely fine. We still need it for async tasks/callbacks.

Yury

More information about the Python-Dev mailing list