On Tue, Jan 2, 2018 at 4:30 PM, Victor Stinner <victor.stin...@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)
_______________________________________________
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
