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

[Guido van Rossum]

On Thu, Jan 4, 2018 at 4:11 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> 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:
> >> 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).
> >
>
[Nathaniel]

> > 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.
>
> [Paul]

> 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.
>

In the other thread I think we've clarified what the (im)mutability status
of Context is. I don't think we need Victor's implementation either and I
agree with Paul that the PEP just needs a better specification /
description of the API it offers. Also let's not tweak the name of the
function that retrieves a copy of the current context just yet. The PEP has
it as copy_context(). Let's keep that.

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