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...@gmail.com> wrote: > On Wed, Oct 18, 2017 at 2:21 PM, Guido van Rossum <gu...@python.org> > wrote: > > On Wed, Oct 18, 2017 at 10:50 AM, Yury Selivanov < > yselivanov...@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). > > '_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 > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
