On Wed, Jan 3, 2018 at 6:45 PM, Victor Stinner
wrote:
> Is it possible to run a generator in a context explicitly using PEP
> 567 Context.run() API?
>
Yes. You execute 'ctx = copy_context()' once, and then wrap all .next()
calls in ctx.run(). This is what the PEP proposes to do for asyncio.Task
On Thu, Jan 4, 2018 at 4:11 AM, Paul Moore wrote:
> On 4 January 2018 at 02:15, Nathaniel Smith wrote:
> > On Wed, Jan 3, 2018 at 5:42 PM, Victor Stinner
> wrote:
> >> It seems like many people, including myself, are confused by the lack
> >> of concrete current context in the PEP 567 (contextv
On 4 January 2018 at 02:15, Nathaniel Smith wrote:
> On Wed, Jan 3, 2018 at 5:42 PM, Victor Stinner
> wrote:
>> Hi,
>>
>> It seems like many people, including myself, are confused by the lack
>> of concrete current context in the PEP 567 (contextvars). But it isn't
>> difficult to implement the
2018-01-04 3:15 GMT+01:00 Nathaniel Smith :
> The problem with such an API is that it doesn't work (or at the very
> least creates a lot of complications) in a potential future PEP 550
> world, (...)
Hum, it's annoying that many design choices of the PEP 567 are
motivated by the hypothetical accep
On Wed, Jan 3, 2018 at 5:42 PM, Victor Stinner wrote:
> Hi,
>
> It seems like many people, including myself, are confused by the lack
> of concrete current context in the PEP 567 (contextvars). But it isn't
> difficult to implement the current context (I implemented it, see
> below).
The problem
Victor:
> I modified Context mapping API to use the context variables from the
> current thread state if it's the current thread state.
Oops, I mean: "if it's the current context".
Nathaniel:
"""
- BUT it doesn't allow mutation through the MutableMapping interface;
instead, the only way to mutate
