On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith <n...@pobox.com> wrote:
> On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum <gu...@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. > - 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. > 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"?) -- --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
