[Python-Dev] PEP 567 v2 (original) (raw)

Guido van Rossum guido at python.org
Thu Jan 4 21:09:45 EST 2018


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>



More information about the Python-Dev mailing list