<div dir="ltr">Actually after <a href="https://bugs.python.org/issue31742">recent debate</a> I think this PEP should *not* be provisional.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 18, 2017 at 11:45 AM, Yury Selivanov <span dir="ltr"><<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Oct 18, 2017 at 2:21 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> On Wed, Oct 18, 2017 at 10:50 AM, Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com">yselivanov.ml@gmail.com</a>><br>
> wrote:<br>
>><br>
>> The main reason why I don't like 'set_ctx()' is because it would make<br>
>> it harder for us to adopt PEP 550-like design later in the future<br>
>> (*if* we need that.)<br>
>><br>
>> PEP 550 is designed in such a way, that 'generator.send()' is the only<br>
>> thing that can control the actual stack of LCs.  If users can call<br>
>> 'set_ctx' themselves, it means that it's no longer safe for<br>
>> 'generator.send()' to simply pop the topmost LC from the stack.  This<br>
>> can be worked around, potentially, but the we don't actually need<br>
>> 'set_ctx' in asyncio or in any other async framework.  There is simply<br>
>> no hard motivation to have it.  That's why I'd like to have just<br>
>> Context.run(), because it's sufficient, and it doesn't burn the bridge<br>
>> to PEP 550-like design.<br>
><br>
><br>
> Honestly that stack-popping in send() always felt fragile to me, so I'd be<br>
> happy if we didn't need to depend on it.<br>
><br>
> That said I'm okay with presenting set_ctx() *primarily* as an educational<br>
> tool for showing how Context.run() works. We could name it _set_ctx() and<br>
> add a similar note as we have for sys._getframe(), basically keeping the<br>
> door open for future changes that may render it non-functional without<br>
> worries about backward compatibility (and without invoking the notion of<br>
> "provisional" API).<br>
<br>
</span>'_set_ctx()' + documentation bits work for me.  I also assume that if<br>
you accept the PEP, you do it provisionally, right?  That should make<br>
it possible for us to *slightly* tweak the<br>
implementation/API/semantics in 3.8 if needed.<br>
<span class=""><br>
> There's no problem with get_ctx() right?<br>
<br>
</span>Yes, 'get_ctx()' is absolutely fine.  We still need it for async<br>
tasks/callbacks.<br>
<span class="HOEnZb"><font color="#888888"><br>
Yury<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>