On 30 August 2017 at 16:40, Nick Coghlan wrote:
> Writing an "update_parent_context" decorator is also trivial (and will
> work for both sync and async generators):
>
> def update_parent_context(gf):
> @functools.wraps(gf):
> def wrapper(*args, **kwds):
> gen = gf(*
On 30 August 2017 at 10:18, Yury Selivanov wrote:
> On Tue, Aug 29, 2017 at 7:36 PM, Greg Ewing
> wrote:
> [..]
>>> For (1) we want the context change to be isolated. For (2) you say
>>> that the context change should propagate to the caller.
>>
>>
>> No, I'm saying that the context change shou
30.08.17 01:52, Antoine Pitrou пише:
https://github.com/python/cpython/commit/bd73e72b4a9f019be514954b1d40e64dc3a5e81c
commit: bd73e72b4a9f019be514954b1d40e64dc3a5e81c
branch: master
author: Allen W. Smith, Ph.D
committer: Antoine Pitrou
date: 2017-08-30T00:52:18+02:00
summary:
bpo-5001: More-
On Tue, Aug 29, 2017 at 7:36 PM, Greg Ewing wrote:
[..]
>> For (1) we want the context change to be isolated. For (2) you say
>> that the context change should propagate to the caller.
>
>
> No, I'm saying that the context change should *always*
> propagate to the caller, unless you do something
On Tue, Aug 29, 2017 at 7:36 PM, Greg Ewing wrote:
> Yury Selivanov wrote:
>>
>> While we want "yield from" to have semantics close to a function call,
>
>
> That's not what I said! I said that "yield from foo()" should
> have semantics close to a function call. If you separate the
> "yield from"
Yury Selivanov wrote:
While we want "yield from" to have semantics close to a function call,
That's not what I said! I said that "yield from foo()" should
have semantics close to a function call. If you separate the
"yield from" from the "foo()", then of course you can get
different behaviours.
On Tue, Aug 29, 2017 at 7:06 PM, Stefan Krah wrote:
> On Tue, Aug 29, 2017 at 06:01:40PM -0400, Yury Selivanov wrote:
>> PEP 550 positions itself as a replacement for TLS, and clearly defines
>> its semantics for regular functions in a single thread, regular
>> functions in multithreaded code, gen
On Tue, Aug 29, 2017 at 06:01:40PM -0400, Yury Selivanov wrote:
> PEP 550 positions itself as a replacement for TLS, and clearly defines
> its semantics for regular functions in a single thread, regular
> functions in multithreaded code, generators, and asynchronous code
> (async/await). Everythin
On Tue, Aug 29, 2017 at 5:45 PM, Greg Ewing wrote:
[..]
> What you seem to be suggesting is that generators shouldn't
> leak context changes even when you *don't* use a with-statement.
Yes, generators shouldn't leak context changes regardless of what and
how changes the context inside them:
va
Yury Selivanov wrote:
Consider the following generator:
def gen():
with decimal.context(...):
yield
We don't want gen's context to leak to the outer scope
That's understandable, but fixing that problem shouldn't come
at the expense of breaking the ability to refacto
On Tue, Aug 29, 2017 at 4:33 PM, Antoine Pitrou wrote:
>
> Le 29/08/2017 à 22:20, Yury Selivanov a écrit :
>>
>> 2)
>>
>>gvar = new_context_var()
>>var = new_context_var()
>>
>>async def bar():
>># EC = [current_thread_LC_copy, Task_foo_LC_copy, Task_wait_for_LC]
>
> Ah, thanks
Le 29/08/2017 à 22:20, Yury Selivanov a écrit :
>
> 2)
>
>gvar = new_context_var()
>var = new_context_var()
>
>async def bar():
># EC = [current_thread_LC_copy, Task_foo_LC_copy, Task_wait_for_LC]
Ah, thanks!... That explains things, though I don't expect most users
to spo
On Tue, Aug 29, 2017 at 4:10 PM, Antoine Pitrou wrote:
[..]
>> "await bar()" and "await wait_for(bar())" are actually quite
>> different. Let me illustrate with an example:
>>
>> b1 = bar()
>> # bar() is not running yet
>> await b1
>>
>> b2 = wait_for(bar())
>> # bar() was wra
On Tue, Aug 29, 2017 at 12:59 PM, Yury Selivanov
wrote:
> b2 = wait_for(bar())
> # bar() was wrapped into a Task and is being running right now
> await b2
Ah not quite. wait_for is itself implemented as a coroutine, so it
doesn't spawn off bar() into its own task until you await b
Le 29/08/2017 à 21:59, Yury Selivanov a écrit :
>
> This absolutely needs to be fixed, and the only way (that I know) it
> can be fixed is to revert the "every coroutine has its own LC"
> statement (going back to the semantics coroutines had in PEP 550 v2
> and v3).
I completely agree with this.
On Tue, Aug 29, 2017 at 12:32 PM, Antoine Pitrou wrote:
>
>
> Le 29/08/2017 à 21:18, Yury Selivanov a écrit :
>> On Tue, Aug 29, 2017 at 2:40 PM, Antoine Pitrou wrote:
>>> On Mon, 28 Aug 2017 17:24:29 -0400
>>> Yury Selivanov wrote:
Long story short, I think we need to rollback our last dec
On Tue, Aug 29, 2017 at 3:32 PM, Antoine Pitrou wrote:
>
>
> Le 29/08/2017 à 21:18, Yury Selivanov a écrit :
>> On Tue, Aug 29, 2017 at 2:40 PM, Antoine Pitrou wrote:
>>> On Mon, 28 Aug 2017 17:24:29 -0400
>>> Yury Selivanov wrote:
Long story short, I think we need to rollback our last deci
Le 29/08/2017 à 21:18, Yury Selivanov a écrit :
> On Tue, Aug 29, 2017 at 2:40 PM, Antoine Pitrou wrote:
>> On Mon, 28 Aug 2017 17:24:29 -0400
>> Yury Selivanov wrote:
>>> Long story short, I think we need to rollback our last decision to
>>> prohibit context propagation up the call stack in co
On Tue, Aug 29, 2017 at 2:40 PM, Antoine Pitrou wrote:
> On Mon, 28 Aug 2017 17:24:29 -0400
> Yury Selivanov wrote:
>> Long story short, I think we need to rollback our last decision to
>> prohibit context propagation up the call stack in coroutines. In PEP
>> 550 v3 and earlier, the following s
On Mon, Aug 28, 2017 at 7:16 PM, Yury Selivanov wrote:
> On Mon, Aug 28, 2017 at 6:56 PM, Greg Ewing
> wrote:
>> Yury Selivanov wrote:
>>>
>>> I saying that the following should not work:
>>>
>>> def nested_gen():
>>> set_some_context()
>>> yield
>>>
>>> def gen():
>>>
On Mon, 28 Aug 2017 17:24:29 -0400
Yury Selivanov wrote:
> Long story short, I think we need to rollback our last decision to
> prohibit context propagation up the call stack in coroutines. In PEP
> 550 v3 and earlier, the following snippet would work just fine:
>
>var = new_context_var()
>
On Tue, Aug 29, 2017 at 10:47 AM, Guido van Rossum wrote:
> On Tue, Aug 29, 2017 at 6:46 AM, Elvis Pranskevichus
> wrote:
>>
>> On Tuesday, August 29, 2017 9:14:53 AM EDT Yury Selivanov wrote:
>> > On Tue, Aug 29, 2017 at 6:53 AM, Nick Coghlan
>> wrote:
>> > > Given the refocusing of the PEP on
On Tuesday, August 29, 2017, Steve Dower wrote:
> On 29Aug2017 0801, Steve Dower wrote:
>
>> On 29Aug2017 0614, Wes Turner wrote:
>>
>>> Wouldn't it be great to have the resources to source audit all code?
>>> (And expect everyone to GPG sign all their commits someday.)
>>>
>>
>> If you care this
On 29Aug2017 0801, Steve Dower wrote:
On 29Aug2017 0614, Wes Turner wrote:
Wouldn't it be great to have the resources to source audit all code?
(And expect everyone to GPG sign all their commits someday.)
If you care this much, then you will find the resources to audit all the
code manually a
On 29Aug2017 0614, Wes Turner wrote:
Wouldn't it be great to have the resources to source audit all code?
(And expect everyone to GPG sign all their commits someday.)
If you care this much, then you will find the resources to audit all the
code manually after you've downloaded it and before yo
On Tue, Aug 29, 2017 at 6:46 AM, Elvis Pranskevichus
wrote:
> On Tuesday, August 29, 2017 9:14:53 AM EDT Yury Selivanov wrote:
> > On Tue, Aug 29, 2017 at 6:53 AM, Nick Coghlan
> wrote:
> > > Given the refocusing of the PEP on the context variable API, with
> > > the
> > > other aspects introduc
On 29 August 2017 at 23:18, Yury Selivanov wrote:
> On Tue, Aug 29, 2017 at 5:01 AM, Nick Coghlan wrote:
> [..]
>> P.S. And I say that as a reader who correctly guessed why you had
>> changed the method name in the current iteration of the proposal. I'm
>> sympathetic to those reasons, but I thin
On Tuesday, August 29, 2017 9:14:53 AM EDT Yury Selivanov wrote:
> On Tue, Aug 29, 2017 at 6:53 AM, Nick Coghlan
wrote:
> > On 28 August 2017 at 01:51, Jim J. Jewett
wrote:
> >> I think there is general consensus that this should go in a module
> >> other than sys. (At least a submodule.)
> >>
On Tue, Aug 29, 2017 at 5:01 AM, Nick Coghlan wrote:
[..]
> P.S. And I say that as a reader who correctly guessed why you had
> changed the method name in the current iteration of the proposal. I'm
> sympathetic to those reasons, but I think sticking with the
> conventional API will make this one
On Tue, Aug 29, 2017 at 6:53 AM, Nick Coghlan wrote:
> On 28 August 2017 at 01:51, Jim J. Jewett wrote:
>> I think there is general consensus that this should go in a module other
>> than sys. (At least a submodule.)
>>
>> The specific names are still To Be Determined, but I suspect seeing the
>>
On Monday, August 28, 2017, Steve Dower wrote:
> On 28Aug2017 1834, Gregory P. Smith wrote:
>
>> My gut feeling says that there are N interpreters available on just
>> about every bloated system image out there. Multiple pythons are often
>> among them, other we do not control will also continue
On 29 August 2017 at 07:24, Yury Selivanov wrote:
> This means that PEP 550 will have a caveat for async code: don't rely
> on context propagation up the call stack, unless you are writing
> __aenter__ and __aexit__ that are guaranteed to be called without
> being wrapped into a Task.
I'm not sur
On 28 August 2017 at 01:51, Jim J. Jewett wrote:
> I think there is general consensus that this should go in a module other
> than sys. (At least a submodule.)
>
> The specific names are still To Be Determined, but I suspect seeing the
> functions and objects as part of a named module will affect
On 27 August 2017 at 03:23, Yury Selivanov wrote:
> On Sat, Aug 26, 2017 at 1:23 PM, Ethan Furman wrote:
>> On 08/26/2017 09:25 AM, Yury Selivanov wrote:
>>> ContextVar.lookup() method *traverses the stack* until it finds the LC
>>> that has a value. "get()" does not reflect this subtle semantic
34 matches
Mail list logo
