Hi Eric, On Fri, Sep 1, 2017 at 11:29 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
Nice working staying on top of this! Keeping up with discussion is arguably much harder than actually writing the PEP. :) I have some comments in-line below.
Thanks!
-eric
On Fri, Sep 1, 2017 at 5:02 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
[snip]
Abstract ========
[snip]
Rationale =========
[snip]
Goals =====
I still think that the Abstract, Rationale, and Goals sections should be clear that a major component of this proposal is lookup via chained contexts. Without such clarity it may not be apparent that chained lookup is not strictly necessary to achieve the stated goals (i.e. an async-compatible TLS replacement). This matters because the chaining introduces extra non-trivial complexity.
Let me walk you through the history of PEP 550 to explain how we arrived to having "chained lookups". If we didn't have generators in Python, the first version of PEP 550 ([1]) would have been a perfect solution. First let's recap the how all versions of PEP 550 reason about generators: * generators can be paused/resumed at any time by code they cannot control; * thus any context changes in a generator should be isolated, and visible only to the generator and code it runs. PEP 550 v1 had excellent performance characteristics, a specification that was easy to fully understand, and a relatively straightforward implementation. It also had *no* chained lookups, as there was only one thread-specific collection of context values. PEP 550 states that v1 was rejected because of the following reason: "The fundamental limitation that caused a complete redesign of the first version was that it was not possible to implement an iterator that would interact with the EC in the same way as generators". I believe it's no longer true: I think that we could use the same trick [2] we use in the current version of PEP 550. But that doesn't really matter. The fundamental problem of PEP 550 v1 was that generators could not see EC updates *while being iterated*. Let's look at the following: def gen(): yield some_decimal_calculation() yield some_decimal_calculation() yield some_decimal_calculation() with decimal_context_0: g = gen() with decimal_context_1: next(g) with decimal_context_2: next(g) In the above example, with PEP 550 v1, generator 'g' would snapshot the execution context at the point where it was created. So all calls to "some_decimal_calculation()" would be made with "decimal_context_0". We could easily change the semantics to snapshot the EC at the point of the first iteration, but that would only make "some_decimal_calculation()" to be always called with "decimal_context_1". In this email [3], Nathaniel explained that there are use cases where seeing updates in the surrounding Execution Context matters in some situations. One case is his idea to implement special timeouts handling in his async framework Trio. Another one, is backwards compatibility: currently, if you use a "threading.local()", you should be able to see updates in it while the generator is being iterated. With PEP 550 v1, you couldn't. To fix this problem, in later versions of PEP 550, we transformed the EC into a stack of Logical Contexts. Every generator has its own LC, which contains changes to the EC local to that generator. Having a stack naturally made it a requirement to have "chained" lookups. That's how we fixed the above example! Therefore, while the current version of PEP 550 is more complex than v1, it has a *proper* support of generators. It provides strong guarantees w.r.t. context isolation, and at the same time maintains their ability to see the full outer context while being iterated. [..]
Speaking of which, I have plans for the near-to-middle future that involve making use of the PEP 550 functionality in a way that is quite similar to decimal. However, it sounds like the implementation of such (namespace) contexts under PEP 550 is much more complex than it is with threading.local (where subclassing made it easy). It would be helpful to have some direction in the PEP on how to port to PEP 550 from threading.local. It would be even better if the PEP included the addition of a contextlib.Context or contextvars.Context class (or NamespaceContext or ContextNamespace or ...). :) However, I recognize that may be out of scope for this PEP.
Currently we are focused on refining the fundamental low-level APIs and data structures, and the scope we cover in the PEP is already huge. Adding high-level APIs is much easier, so yeah, I'd discuss them if/after the PEP is accepted. Thanks! Yury [1] https://github.com/python/peps/blob/e8a06c9a790f39451d9e99e203b13b3ad73a1d01... [2] https://www.python.org/dev/peps/pep-0550/#generators-transformed-into-iterat... [3] https://mail.python.org/pipermail/python-ideas/2017-August/046736.html