[Python-Dev] PEP 550 v4

Nick Coghlan ncoghlan at gmail.com
Thu Sep 7 20:06:23 EDT 2017


On 7 September 2017 at 07:06, Ethan Furman <ethan at stoneleaf.us> wrote:
> The concern is *how* PEP 550 provides it:
>
> - explicitly, like threading.local(): has to be set up manually,
>   preferably with a context manager
>
> - implicitly: it just happens under certain conditions

A recurring point of confusion with the threading.local() analogy
seems to be that there are actually *two* pieces to that analogy:

* threading.local() <-> contextvars.ContextVar
* PyThreadState_GetDict() <-> LogicalContext

(See https://github.com/python/cpython/blob/a6a4dc816d68df04a7d592e0b6af8c7ecc4d4344/Python/pystate.c#L584
for the definition of the PyThreadState_GetDict)

For most practical purposes as a *user* of thread locals, the
involvement of PyThreadState and the state dict is a completely hidden
implementation detail. However, every time you create a new thread,
you're implicitly getting a new Python thread state, and hence a new
thread state dict, and hence a new set of thread local values.

Similarly, as a *user* of context variables, you'll generally be able
to ignore the manipulation of the execution context going on behind
the scenes - you'll just get, set, and delete individual context
variables without worrying too much about exactly where and how
they're stored.

PEP 550 itself doesn't have that luxury, though, since in addition to
defining how users will access and update these values, it *also*
needs to define how the interpreter will implicitly manage the
execution context for threads and generators and how event loops
(including asyncio as the reference implementation) are going to be
expected to manage the execution context explicitly when scheduling
coroutines.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list