[Python-Dev] PEP 550 v4

Greg Ewing greg.ewing at canterbury.ac.nz
Thu Sep 7 07:19:20 EDT 2017


There is one thing I misunderstood. Since generators and
coroutines are almost exactly the same underneath, I had
thought that the automatic logical_context creation for
generators was also going to apply to coroutines, but
from reading the PEP again it seems that's not the case.
Somehow I missed that the first time. Sorry about that.

So, context vars do behave like "task locals storage"
for asyncio Tasks, which is good.

The only issue is whether a generator should be considered
an "ad-hoc task" for this purpose. I can see your reasons
for thinking that it should be. I can also understand your
thinking that the yield-from issue is such an obscure
corner case that it's not worth worrying about,
especially since there is a workaround available (setting
_logical_context_ to None) if needed.

I'm not sure how I feel about that now. I agree that
it's an obscure case, but the workaround seems even more
obscure, and is unlikely to be found by anyone who
isn't closely familiar with the inner workings.

I think I'd be happier if there were a higher-level way
of applying this workaround, such as a decorator:

@subgenerator
def g():
    ...

Then the docs could say "If you want a generator to *not*
have its own task local storage, wrap it with @subgenerator."

By the way, I think "Task Local Storage" would be a
much better title for this PEP. It instantly conveys the
basic idea in a way that "Execution Context" totally
fails to do.

It might also serve as a source for some better
terminology for parts of the implementation, such as
TaskLocalStorage and TaskLocalStorageStack instead
of logical_context and execution_context. I found
the latter terms almost devoid of useful meaning when
trying to understand the implementation.

-- 
Greg



More information about the Python-Dev mailing list