[Python-Dev] Timeout for PEP 550 / Execution Context discussion
Guido van Rossum
guido at python.org
Mon Oct 16 13:00:14 EDT 2017
On Mon, Oct 16, 2017 at 9:11 AM, Yury Selivanov <yselivanov.ml at gmail.com>
> On Mon, Oct 16, 2017 at 11:49 AM, Guido van Rossum <guido at python.org>
> > On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith <njs at 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
> > 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.
> >> 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
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
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev