[Python-Dev] Timeout for PEP 550 / Execution Context discussion

[Guido van Rossum]

Hm. I really like the idea that you can implement and demonstrate all of
ContextVar by manipulating the underlying mapping. And surely compared to
the effort of implementing the HAMT itself (including all its edge cases)
surely implementing the mutable mapping API should be considered
recreational programming.

On Mon, Oct 16, 2017 at 5:57 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Mon, Oct 16, 2017 at 8:49 AM, Guido van Rossum <guido at python.org>
> wrote:
> > On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith <njs at pobox.com> wrote:
> >>
> >> On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum <guido at python.org>
> >> wrote:
> >> > Yes, that's what I meant by "ignoring generators". And I'd like there
> to
> >> > be
> >> > a "current context" that's a per-thread MutableMapping with ContextVar
> >> > keys.
> >> > Maybe there's not much more to it apart from naming the APIs for
> getting
> >> > and
> >> > setting it? To be clear, I am fine with this being a specific subtype
> of
> >> > MutableMapping. But I don't see much benefit in making it more
> abstract
> >> > than
> >> > that.
> >>
> >> We don't need it to be abstract (it's fine to have a single concrete
> >> mapping type that we always use internally), but I think we do want it
> >> to be opaque (instead of exposing the MutableMapping interface, the
> >> only way to get/set specific values should be through the ContextVar
> >> interface). The advantages are:
> >>
> >> - This allows C level caching of values in ContextVar objects (in
> >> particular, funneling mutations through a limited API makes cache
> >> invalidation *much* easier)
> >
> >
> > Well the MutableMapping could still be a proxy or something that
> invalidates
> > the cache when mutated. That's why I said it should be a single concrete
> > mapping type. (It also doesn't have to derive from MutableMapping -- it's
> > sufficient for it to be a duck type for one, or perhaps some Python-level
> > code could `register()` it.
>
> MutableMapping is just a really complicated interface -- you have to
> deal with iterator invalidation and popitem and implementing view
> classes and all that. It seems like a lot of code for a feature that
> no-one seems to worry about missing right now. (In fact, I suspect the
> extra code required to implement the full MutableMapping interface on
> top of a basic HAMT type is larger than the extra code to implement
> the current PEP 550 draft's chaining semantics on top of this proposal
> for a minimal PEP 550.)
>
> What do you think of something like:
>
> class Context:
>     def __init__(self, /, init: MutableMapping[ContextVar,object] = {}):
>         ...
>
>     def as_dict(self) -> Dict[ContextVar, object]:
>         "Returns a snapshot of the internal state."
>
>     def copy(self) -> Context:
>         "Equivalent to (but maybe faster than) Context(self.as_dict())."
>
> I like the idea of making it possible to set up arbitrary Contexts and
> introspect them, because sometimes you do need to debug weird issues
> or do some wacky stuff deep in the guts of a coroutine scheduler, but
> this would give us that without implementing MutableMapping's 17
> methods and 7 helper classes.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>



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