On Tue, Jan 2, 2018 at 5: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 implemention (designed for best performances). > Yeah, we need some more words. I still hope someone proposes some, but if threats fail I will have to try to find time myself. > 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() switchs > temporarely 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. > I think the issue here is a bit different than Yury's response suggests -- it's more like how a variable containing an immutable value (e.g. a string) can be modified, e.g. x = 'a' x += 'b' In our case the *variable* is the current thread state (in particular the slot therein that holds the context -- this slot can be modified by the C API). The *value* is the Context object. It is a collections.Mapping (or typing.Mapping) which does not have mutating methods. (The mutable type is called MutableMapping.) The *reason* for doing it this way is that Yury doesn't want Context to implement __delitem__, since it would complicate the specification of chained lookups by a future PEP, and chained lookups look to be the best option to extend the Context machinery for generators. We're not doing that in Python 3.7 (PEP 550 v2 and later did this but it was too complex) but we might want to do in 3.8 or 3.9 once we are comfortable with PEP 567. (Or not -- it's not clear to me that generators bite decimal users the way tasks do. Coroutines always run on behalf of a task so they're not a problem.) --Guido > Victor > > Le 3 janv. 2018 00:34, "Victor Stinner" <victor.stin...@gmail.com> a > écrit : > >> > 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 >> > -- --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
