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

[Guido van Rossum]

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 '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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171018/fd449f4e/attachment.html>