[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:53:25 EDT 2017

Actually after recent debate <https://bugs.python.org/issue31742> I think this PEP should not be provisional.

On Wed, Oct 18, 2017 at 11:45 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:

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).

'setctx()' + 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, 'getctx()' is absolutely fine. We still need it for async tasks/callbacks. Yury

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171018/fd449f4e/attachment.html>

More information about the Python-Dev mailing list