[Python-Dev] PEP 567 v2

[Guido van Rossum]

On Tue, Jan 2, 2018 at 4:30 PM, Victor Stinner <victor.stinner at gmail.com>
wrote:

> Hum, it seems like the specification (API) part of the PEP is polluted by
> its implementation. The PEP just require a few minor changes to better
> describe the behaviour/API instead of insisting on the read only internal
> thing which is specific to the proposed implementation which is just one
> arbitrary implementation (designed for best performances).
>
> IMHO the PEP shouldn't state that a context is read only. From my point of
> view, it's mutable and it's the mapping holding variable values. There is a
> current context which holds the current values. Context.run() switches
> temporarily the current context with another context. The fact that there
> is no concrete context instance by default doesn't really matter in term of
> API.
>

You've convinced me that Context is neither immutable nor read-only, and
the PEP should admit this. Its *Mapping* interface doesn't allow mutations
but its run() method does. E.g. here's a function that mutates a Context,
effectively doing vtx[var] = value:

def mutate_context(ctx, var, value):
    ctx.run(lambda: var.set(value))

However you've not convinced me that it would be better to make Context
implement the full MutableMapping interface (with `__delitem__` always
raising). There are use cases for inspecting Context, e.g. a debugger that
wants to print the Context for some or all suspended tasks. But I don't see
a use case for mutating a Context object that's not the current context,
and when it is the current context, ContextVar.set() is more direct. I also
don't see use cases for other MutableMapping methods like pop() or
update(). (And clear() falls under the same prohibition as __delitem__().)

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