(original) (raw)

On Wed, Oct 18, 2017 at 2:21 PM, Guido van Rossum <guido@python.org> wrote:
\> On Wed, Oct 18, 2017 at 10:50 AM, Yury Selivanov <yselivanov.ml@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