On 7 September 2017 at 07:06, Ethan Furman <ethan@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/a6a4dc816d68df04a7d592e0b6af8c7ecc4d4... 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@gmail.com | Brisbane, Australia