[Python-Dev] PEP 550 v4

Guido van Rossum guido at python.org
Mon Aug 28 21:50:17 EDT 2017


On Mon, Aug 28, 2017 at 6:07 PM, Nathaniel Smith <njs at pobox.com> wrote:

> The important difference between generators/coroutines and normal
> function calls is that with normal function calls, the link between
> the caller and callee is fixed for the entire lifetime of the inner
> frame, so there's no way for the context to shift under your feet. If
> all we had were normal function calls, then (green-) thread locals
> using the save/restore trick would be enough to handle all the use
> cases above -- it's only for generators/coroutines where the
> save/restore trick breaks down. This means that pushing/popping LCs
> when crossing into/out of a generator frame is the minimum needed to
> get the desired semantics, and it keeps the LC stack small (important
> since lookups can be O(n) in the worst case), and it minimizes the
> backcompat breakage for operations like decimal.setcontext() where
> people *do* expect to call it in a subroutine and have the effects be
> visible in the caller.
>

I like this way of looking at things. Does this have any bearing on
asyncio.Task? To me those look more like threads than like generators. Or
possibly they should inherit the lookup chain from the point when the Task
was created, but not be affected at all by the lookup chain in place when
they are executed. FWIW we *could* have a policy that OS threads also
inherit the lookup chain from their creator, but I doubt that's going to
fly with backwards compatibility.

I guess my general (hurried, sorry) view is that we're at a good point
where we have a small number of mechanisms but are still debating policies
on how those mechanisms should be used. (The basic mechanism is chained
lookup and the policies are about how the chains are fit together for
various language/library constructs.)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170828/632bb02f/attachment.html>


More information about the Python-Dev mailing list