[Python-Dev] PEP 567 v2

[Victor Stinner]

> I would really like to invite more people to review this PEP! I expect
I'll be accepting it in the next two weeks, but it needs to go through more
rigorous review.

I read again the PEP and I am still very confused by Context.run().

The PEP states multiple times that a context is immutable:

* "read-only mapping"
* inherit from Mapping, not from MutableMapping

But run() does modify the context (or please correct me if I
completely misunderstood
the PEP! I had to read it 3 times to check if run() mutates or not the
context).

It would help if the ctx.run() example in the PEP would not only test
var.get() but also test ctx.get(var). Or maybe show that the variable value
is kept in a second function call, but the variable is "restored" between
run() calls.

The PEP tries hard to hide "context data", which is the only read only
thing in the whole PEP, whereas it's a key concept to understand the
implementation.

I understood that:

* _ContextData is immutable
* ContextVar.set() creates a new _ContextData and sets it in the current
Python thread state
* When the called function completes, Context.run() sets its context data
to the new context data from the Python thread state: so run() does modify
the "immutable" context


The distinction between the internal/hiden *immutable* context data and
public/visible "mutable" (from my point of view) context is unclear to me
in the PEP.

The concept of "current context" is not defined in the PEP. In practice,
there is no "current context", there is only a "current context data" in
the current Python thread. There is no need for a concrete context instance
to store variable variables values. It's also hard to understand that in
the PEP.


Why Context could not inherit from MutableMapping? (Allow ctx.set(var,
value) and ctx [var] = value.) Is it just to keep the API small: changes
should only be made using var.set()?

Or maybe Context.run() should really be immutable and return the result of
the called function *and* a new context? But I dislike such theorical API,
since it would be complex to return the new context if the called function
raises an exception.

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180103/7bda2bb7/attachment.html>