On Wed, Oct 18, 2017 at 2:21 PM, Guido van Rossum <[email protected]> wrote: > On Wed, Oct 18, 2017 at 10:50 AM, Yury Selivanov <[email protected]> > 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).
'_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 get_ctx() right? Yes, 'get_ctx()' is absolutely fine. We still need it for async tasks/callbacks. Yury _______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com