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: >> 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 _______________________________________________ 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
