(original) (raw)
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).
There's no problem with get\_ctx() right?