Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 19 October 2017 at 04:53, Guido van Rossum wrote: > Actually after recent debate I think > this PEP should *not* be provisional. > +1 from me - "contextvars._set_ctx()" is the only part I think we're really unsure about in your latest API design, and marki

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

Actually after recent debate I think this PEP should *not* be provisional. On Wed, Oct 18, 2017 at 11:45 AM, Yury Selivanov wrote: > On Wed, Oct 18, 2017 at 2:21 PM, Guido van Rossum > wrote: > > On Wed, Oct 18, 2017 at 10:50 AM, Yury Selivanov < > yselivano

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Wed, Oct 18, 2017 at 2:21 PM, Guido van Rossum wrote: > On Wed, Oct 18, 2017 at 10:50 AM, Yury Selivanov > wrote: >> >> The main reason why I don't like 'set_ctx()' is because it would make >> it harder for us to adopt PEP 550-like design later in the future >> (*if* we need that.) >> >> PEP 5

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Wed, Oct 18, 2017 at 10:50 AM, Yury Selivanov wrote: > The main reason why I don't like 'set_ctx()' is because it would make > it harder for us to adopt PEP 550-like design later in the future > (*if* we need that.) > > PEP 550 is designed in such a way, that 'generator.send()' is the only > t

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Wed, Oct 18, 2017 at 2:10 PM, Ethan Furman wrote: [..] > Unless it's extremely difficult to not seg-fault in such a situation I don't > think this is a valid argument. Well, you don't think so, but I do, after writing a few implementations of this PEP family. It would complicate the design, b

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 10/18/2017 10:50 AM, Yury Selivanov wrote: On Wed, Oct 18, 2017 at 1:06 PM, Guido van Rossum wrote: On Tue, Oct 17, 2017 at 9:40 PM, Nick Coghlan wrote: [..] By contrast, "contextvars.set_ctx" would need various wrappers to handle correctly reverting the context change, and would hence be

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Wed, Oct 18, 2017 at 1:06 PM, Guido van Rossum wrote: > On Tue, Oct 17, 2017 at 9:40 PM, Nick Coghlan wrote: [..] >> By contrast, "contextvars.set_ctx" would need various wrappers to handle >> correctly reverting the context change, and would hence be prone to "changed >> the active context wi

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Tue, Oct 17, 2017 at 9:40 PM, Nick Coghlan wrote: > On 18 October 2017 at 05:55, Yury Selivanov > wrote: > >> I actually like what you did in >> https://github.com/gvanrossum/pep550/blob/master/simpler.py, it seems >> reasonable. The only thing that I'd change is to remove "set_ctx" >> from

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 18 October 2017 at 16:25, Ethan Furman wrote: > On 10/17/2017 09:40 PM, Nick Coghlan wrote: > >> At the Python API layer, we don't expose the ability to switch explicitly >> to another thread state while remaining within >> the current function. Instead, we only offer two options: starting a n

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 10/17/2017 09:40 PM, Nick Coghlan wrote: On 18 October 2017 at 05:55, Yury Selivanov wrote: I actually like what you did in https://github.com/gvanrossum/pep550/blob/master/simpler.py , it seems reasonable. The only thing that I'

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 18 October 2017 at 05:55, Yury Selivanov wrote: > On Tue, Oct 17, 2017 at 2:25 PM, Guido van Rossum > wrote: > > On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov > > [..] > >> My way of thinking about this: "get_execution_context()" returns you a > >> shallow copy of the current EC (at least

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Tue, Oct 17, 2017 at 12:51 PM, Nathaniel Smith wrote: > On Oct 17, 2017 11:25 AM, "Guido van Rossum" wrote: > > > In short, I really don't think there's a need for context variables to be > faster than instance variables. > > > There really is: currently the cost of looking up a thread local

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Tue, Oct 17, 2017 at 2:25 PM, Guido van Rossum wrote: > On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov [..] >> My way of thinking about this: "get_execution_context()" returns you a >> shallow copy of the current EC (at least conceptually). So making any >> modifications on it won't affect t

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Oct 17, 2017 11:25 AM, "Guido van Rossum" wrote: In short, I really don't think there's a need for context variables to be faster than instance variables. There really is: currently the cost of looking up a thread local through the C API is a dict lookup, which is faster than instance varia

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

Also, IMO this is all the interface we should need to explain to users (even framework authors): https://github.com/gvanrossum/pep550/blob/master/simpler.py On Tue, Oct 17, 2017 at 11:25 AM, Guido van Rossum wrote: > On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov > wrote: > >> On Tue, Oct 17,

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov wrote: > On Tue, Oct 17, 2017 at 1:02 AM, Nick Coghlan wrote: > > The reason I say that is because one of the biggest future-proofing > concerns > > when it comes to exposing a mapping as the lowest API layer is that it > makes > > the following co

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Tue, Oct 17, 2017 at 1:02 AM, Nick Coghlan wrote: > On 17 October 2017 at 14:31, Guido van Rossum wrote: >> >> No, that version just defers to magic in ContextVar.get/set, whereas what >> I'd like to see is that the latter are just implemented in terms of >> manipulating the mapping directly.

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Mon, Oct 16, 2017 at 10:02 PM, Nick Coghlan wrote: > On 17 October 2017 at 14:31, Guido van Rossum wrote: > >> No, that version just defers to magic in ContextVar.get/set, whereas what >> I'd like to see is that the latter are just implemented in terms of >> manipulating the mapping directly.

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 17 October 2017 at 15:02, Nick Coghlan wrote: > On 17 October 2017 at 14:31, Guido van Rossum wrote: > >> No, that version just defers to magic in ContextVar.get/set, whereas what >> I'd like to see is that the latter are just implemented in terms of >> manipulating the mapping directly. The

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 17 October 2017 at 14:31, Guido van Rossum wrote: > No, that version just defers to magic in ContextVar.get/set, whereas what > I'd like to see is that the latter are just implemented in terms of > manipulating the mapping directly. The only operations for which speed > matters would be __geti

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

No, that version just defers to magic in ContextVar.get/set, whereas what I'd like to see is that the latter are just implemented in terms of manipulating the mapping directly. The only operations for which speed matters would be __getitem__ and __setitem__; most other methods just defer to those.

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 17 October 2017 at 03:00, Guido van Rossum wrote: > On Mon, Oct 16, 2017 at 9:11 AM, Yury Selivanov > wrote: > >> > I agree, but I don't see how making the type a subtype (or duck type) of >> > MutableMapping prevents any of those strategies. (Maybe you were >> equating >> > MutableMapping wi

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

Hm. I really like the idea that you can implement and demonstrate all of ContextVar by manipulating the underlying mapping. And surely compared to the effort of implementing the HAMT itself (including all its edge cases) surely implementing the mutable mapping API should be considered recreational

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 10/16/2017 05:29 PM, Nathaniel Smith wrote: On Mon, Oct 16, 2017 at 11:12 AM, Ethan Furman wrote: What would be really nice is to have attribute access like thread locals. Instead of working with individual ContextVars you grab the LocalContext and access the vars as attributes. I don't re

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Mon, Oct 16, 2017 at 8:49 AM, Guido van Rossum wrote: > On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith wrote: >> >> On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum >> wrote: >> > Yes, that's what I meant by "ignoring generators". And I'd like there to >> > be >> > a "current context" th

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Mon, Oct 16, 2017 at 11:12 AM, Ethan Furman wrote: > What would be really nice is to have attribute access like thread locals. > Instead of working with individual ContextVars you grab the LocalContext and > access the vars as attributes. I don't recall reading in the PEP why this > is a bad i

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 10/16/2017 09:11 AM, Yury Selivanov wrote: Question: why do we want EC objects to be mappings? I'd rather make them opaque, which will result in less code and make it more future-proof. The key arguments for keeping ContextVar abstraction: * Naturally avoids name clashes. * Allows to impl

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Mon, Oct 16, 2017 at 9:53 AM, Yury Selivanov wrote: > I think we can still implement context isolation in generators in > later versions for ContextVars. In 3.7, ContextVars will only support > async tasks and threads. Using them in generators will be > *documented* as unsafe, as the context

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Mon, Oct 16, 2017 at 9:11 AM, Yury Selivanov wrote: > On Mon, Oct 16, 2017 at 11:49 AM, Guido van Rossum > wrote: > > On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith wrote: > >> We don't need it to be abstract (it's fine to have a single concrete > >> mapping type that we always use intern

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Mon, Oct 16, 2017 at 7:44 AM, Nick Coghlan wrote: [..] > So going down this path would lock in the *default* semantics for the > interaction between context variables and generators as being the same as > the interaction between thread locals and generators, but would still leave > the door ope

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Mon, Oct 16, 2017 at 11:49 AM, Guido van Rossum wrote: > On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith wrote: >> >> On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum >> wrote: >> > Yes, that's what I meant by "ignoring generators". And I'd like there to >> > be >> > a "current context" t

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith wrote: > On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum > wrote: > > Yes, that's what I meant by "ignoring generators". And I'd like there to > be > > a "current context" that's a per-thread MutableMapping with ContextVar > keys. > > Maybe th

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 16 October 2017 at 12:44, Nick Coghlan wrote: > The downside is that you'll still need to explicitly revert the decimal > context before yielding from a generator if you didn't want the context > change to "leak", but that's not a new constraint - it's one that already > exists for the thread-l

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 16 October 2017 at 18:26, Paul Moore wrote: > On 16 October 2017 at 02:33, Yury Selivanov > wrote: > > Stage 1. A new execution context PEP to solve the problem *just for > > async code*. The PEP will target Python 3.7 and completely ignore > > synchronous generators and asynchronous generat

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 16 October 2017 at 02:33, Yury Selivanov wrote: > Stage 1. A new execution context PEP to solve the problem *just for > async code*. The PEP will target Python 3.7 and completely ignore > synchronous generators and asynchronous generators. It will be based > on PEP 550 v1 (no chained lookups,

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum wrote: > On Sun, Oct 15, 2017 at 8:17 PM, Nathaniel Smith wrote: >> >> On Sun, Oct 15, 2017 at 6:33 PM, Yury Selivanov >> wrote: >> > Stage 1. A new execution context PEP to solve the problem *just for >> > async code*. The PEP will target Pyth

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Sun, Oct 15, 2017 at 8:17 PM, Nathaniel Smith wrote: > On Sun, Oct 15, 2017 at 6:33 PM, Yury Selivanov > wrote: > > Stage 1. A new execution context PEP to solve the problem *just for > > async code*. The PEP will target Python 3.7 and completely ignore > > synchronous generators and asynchr

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Sun, Oct 15, 2017 at 8:12 PM, Nick Coghlan wrote: > On 16 October 2017 at 11:33, Yury Selivanov > wrote: > >> Stage 2. When Python 3.7 is out, we'll see how people use execution >> contexts for async code and collect feedback. If we recognize that >> Python users want execution contexts for

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Sun, Oct 15, 2017 at 6:33 PM, Yury Selivanov wrote: > Hi, > > It looks like the discussion about the execution context became > extremely hard to follow. There are many opinions on how the spec for > generators should look like. What seems to be "natural" > behaviour/example to one, seems to

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 16 October 2017 at 11:33, Yury Selivanov wrote: > Stage 2. When Python 3.7 is out, we'll see how people use execution > contexts for async code and collect feedback. If we recognize that > Python users want execution contexts for generators/asynchronous > generators, we'll make a new PEP to a

[Python-Dev] Timeout for PEP 550 / Execution Context discussion

Hi, It looks like the discussion about the execution context became extremely hard to follow. There are many opinions on how the spec for generators should look like. What seems to be "natural" behaviour/example to one, seems to be completely unreasonable to other people. Recent emails from Gui