On Mon, Oct 16, 2017 at 9:11 AM, Yury Selivanov <yselivanov...@gmail.com> wrote:
> On Mon, Oct 16, 2017 at 11:49 AM, Guido van Rossum <gu...@python.org> > wrote: > > On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith <n...@pobox.com> wrote: > >> 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. > > Yeah, we can do a proxy. > > >> - It gives us flexibility to change the underlying data structure > >> without breaking API, or for different implementations to make > >> different choices -- in particular, it's not clear whether a dict or > >> HAMT is better, and it's not clear whether a regular dict or > >> WeakKeyDict is better. > > > I would keep it simple and supid, but WeakKeyDict is a subtype of > > MutableMapping, and I'm sure we can find a way to implement the full > > MutableMapping interface on top of HAMT as well. > > Correct. > > >> The first point (caching) I think is the really compelling one: in > >> practice decimal and numpy are already using tricky caching code to > >> reduce the overhead of accessing the ThreadState dict, and this gets > >> even trickier with context-local state which has more cache > >> invalidation points, so if we don't do this in the interpreter then it > >> could actually become a blocker for adoption. OTOH it's easy for the > >> interpreter itself to do this caching, and it makes everyone faster. > > > I agree, but I don't see how making the type a subtype (or duck type) of > > MutableMapping prevents any of those strategies. (Maybe you were equating > > MutableMapping with "subtype of dict"?) > > Question: why do we want EC objects to be mappings? I'd rather make > them opaque, which will result in less code and make it more > future-proof. > I'd rather have them mappings, since that's what they represent. It helps users understand what's going on behind the scenes, just like modules, classes and (most) instances have a `__dict__` that you can look at and (in most cases) manipulate. > The key arguments for keeping ContextVar abstraction: > To be clear, I do want to keep ContextVar! > * Naturally avoids name clashes. > > * Allows to implement efficient caching. This is important if we want > libraries like decimal/numpy to start using it. > > * Abstracts away the actual implementation of the EC. This is a > future-proof solution, with which we can enable EC support for > generators in the future. We already know two possible solutions (PEP > 550 v1, PEP 550 current), and ContextVar is a good enough abstraction > to support both of them. > > IMO ContextVar.set() and ContextVar.get() is a simple and nice API to > work with the EC. Most people (aside framework authors) won't even > need to work with EC objects directly anyways. > Sure. But (unlike you, it seems) I find it important that users can understand their actions in terms of operations on the mapping representing the context. Its type should be a specific class that inherits from `MutableMapping[ContextVar, object]`. -- --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
