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

[Yury Selivanov]

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