On Thu, Jan 4, 2018 at 4:11 AM, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 4 January 2018 at 02:15, Nathaniel Smith <n...@pobox.com> wrote: > > On Wed, Jan 3, 2018 at 5:42 PM, Victor Stinner <victor.stin...@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
