[Python-Dev] PEP 567 (contextvars) idea: really implement the current context

[Paul Moore]

On 4 January 2018 at 02:15, Nathaniel Smith <njs at pobox.com> wrote:
> On Wed, Jan 3, 2018 at 5:42 PM, Victor Stinner <victor.stinner at gmail.com> wrote:
>> Hi,
>>
>> It seems like many people, including myself, are confused by the lack
>> of concrete current context in the PEP 567 (contextvars). But it isn't
>> difficult to implement the current context (I implemented it, see
>> below).
>
> The problem with such an API is that it doesn't work (or at the very
> least creates a lot of complications) in a potential future PEP 550
> world, where the "current context" becomes something like a
> ChainMap-of-Contexts instead of just the last Context that had run()
> called on it. This isn't a big problem for contextvars.get_context(),
> which returns a snapshot of the current context -- in a PEP 550 world
> it would return a snapshot of the current "effective" (flattened)
> context.

But PEP 567 is specifically a restricted version of PEP 550 that
doesn't try to solve the case of generators and async generators -
precisely because it was proving impossible to gain consensus on how
to handle those cases. We can't expect PEP 567 to satisfy an unstated
requirement that "it must be possible to extend it to provide full PEP
550 functionality later". Is there a reason within the stated design
goals of PEP 567 why Victor's implementation is incorrect? In PEP 567
the *only* point of the Context is to provide a means of implementing
the consideration described in the Introduction: "The notion of
"current value" deserves special consideration: different asynchronous
tasks that exist and execute concurrently may have different values
for the same key".

Having said this, I don't really see the need for Victor's
re-implementation. The wording of the PEP needs some work, as it mixes
implementation details with design in a way that makes it confusing,
but unlike Victor I don't see this as unfixable. I'd be perfectly
happy with Yury's implementation, but with better documentation that
focuses on the use of the feature and separates the implementation
aspects out clearly. This seems to be a general problem with async -
usage-focused documentation that ignores implementation details is
very hard to find, and the experts seem to struggle to keep
implementation details "behind the scenes". IMO, we need to do more to
help push for user-friendly documentation, which is why I'd rather
concentrate on helping Yury document context variables in a way that
doesn't expose implementation details, rather than trying to
understand and critique those implementation details (people like
Victor are far better at doing that than I am :-))

> Maybe it would help a little to rename get_context() to something like
> snapshot_context()?

Maybe? But at the moment, the PEP says "the context is immutable" so
it shouldn't make a difference (and in fact get_ makes more sense than
snapshot_ as long as the context is immutable). I'd prefer we work on
clarifying whether (conceptually - not in terms of implementation!)
the context should be described as immutable, and once we understand
that I suspect answers to questions like this will be obvious.

Paul