[Python-Dev] PEP 567 v2

[Yury Selivanov]

On Wed, Jan 3, 2018 at 2:36 AM Victor Stinner <victor.stinner at gmail.com>
wrote:

> > 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
>

tuples in Python are immutable, but you can have a tuple with a dict as its
single element. The tuple is immutable, the dict is mutable.

At the C level we have APIs that can mutate a tuple though.

Now, tuple is not a direct analogy to Context, but there are some
parallels.  Context is a container like tuple, with some additional APIs on
top.


>
> 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()?
>

Because that would be confusing to end users.

  ctx = copy_context()
  ctx[var] = something

What did we just do?  Did we modify the 'var' in the code that is currently
executing? No, you still need to call Context.run to see the new value for
var.

Another problem is that MutableMapping defines a __delitem__ method, which
i don't want the Context to implement.  Deleting variables like that is
incompatible with PEP 550, where it's ambiguous (due to the stacked nature
of contexts).

Now we don't want PEP 550 in 3.7, but I want to keep the door open for its
design, in case we want context to work with generators.


> 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.
>

It can't return a new context because the callable you're running can raise
an exception. In which case you'd lose modifications prior to the error.

ps i'm on vacation and don't always have an internet connection.

yury


> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180103/6f9e4a1f/attachment.html>