Re: [Python-ideas] PEP draft: context variables

On Sun, Oct 15, 2017 at 8:15 AM, Paul Moore wrote: > On 13 October 2017 at 23:30, Yury Selivanov wrote: >> At this point of time, there's just one place which describes one well >> defined semantics: PEP 550 latest version. Paul, if you have >>

Re: [Python-ideas] PEP draft: context variables

Paul Moore writes: > But I do agree with MAL, it seems wrong to need a helper for this, > even though it's a logical consequence of the other semantics I > described as intuitive :-( It seems to me this is an argument for using Haskell if you want life to be simple. :-) Or, in the spirit of

Re: [Python-ideas] PEP draft: context variables

On 16 October 2017 at 21:08, Juancarlo Añez wrote: > > Interestingly, thinking about the problem in terms of exception handling >> flow reminded me of the fact that having a generator-iterator yield while >> inside a with statement or try/except block is already considered an

Re: [Python-ideas] PEP draft: context variables

> Interestingly, thinking about the problem in terms of exception handling > flow reminded me of the fact that having a generator-iterator yield while > inside a with statement or try/except block is already considered an > anti-pattern in many situations, precisely because it means that any >

Re: [Python-ideas] PEP draft: context variables

On 15 October 2017 at 20:45, Paul Moore wrote: > On 15 October 2017 at 06:43, Nick Coghlan wrote: > > > # Generator form > > def _results_gen(data): > > for item in data: > > with adjusted_context(): > >

Re: [Python-ideas] PEP draft: context variables

All this arguing based on "equivalence" between different code fragments is nuts. The equivalences were never meant to be exact, and people don't typically understand code using generators using these equivalencies. The key problem we're trying to address is creating a "context" abstraction that

Re: [Python-ideas] PEP draft: context variables

On 15.10.2017 07:13, Nick Coghlan wrote: > On 15 October 2017 at 14:53, M.-A. Lemburg wrote: >> The behavior of also deferring the context to time of >> execution should be the non-standard form to not break >> this intuition, otherwise debugging will be a pain and >> writing

Re: [Python-ideas] PEP draft: context variables

Generators are a wonderful feature of the python language, and one of its best idea. They are initially very intuitive to understand & easy to use. However, once you get beyond that; they are actually quite confusing because their behavior is not natural. Thus they have a initial easy learning

Re: [Python-ideas] PEP draft: context variables

On 15 October 2017 at 13:51, Amit Green wrote: > Once again, I think Paul Moore gets to the heart of the issue. > > Generators are simply confusing & async even more so. > > Per my earlier email, the fact that generators look like functions, but are > not functions, is at

Re: [Python-ideas] PEP draft: context variables

Once again, I think Paul Moore gets to the heart of the issue. Generators are simply confusing & async even more so. Per my earlier email, the fact that generators look like functions, but are not functions, is at the root of the confusion. This next part really gets to the heart of the matter:

Re: [Python-ideas] PEP draft: context variables

On Sun, Oct 15, 2017 at 06:53:58AM +0200, M.-A. Lemburg wrote: > I have a hard time seeing the advantage of having a default > where the context at the time of execution is dependent on > where it happens rather than where it's defined. > > IMO, the default should be to use the context where the

Re: [Python-ideas] PEP draft: context variables

On 15 October 2017 at 05:39, Nick Coghlan wrote: > On 15 October 2017 at 05:47, Paul Moore wrote: >> >> On 14 October 2017 at 17:50, Nick Coghlan wrote: >> > If you capture the context eagerly, then there are fewer opportunities >> >

Re: [Python-ideas] PEP draft: context variables

On 15 October 2017 at 15:49, Nathaniel Smith wrote: > It's not like this is a new and weird concept in Python either -- e.g. > when you raise an exception, the relevant 'except' block is determined > based on where the 'raise' happens (the runtime stack), not where the > 'raise'

Re: [Python-ideas] PEP draft: context variables

On Sat, Oct 14, 2017 at 9:53 PM, M.-A. Lemburg wrote: > I have a hard time seeing the advantage of having a default > where the context at the time of execution is dependent on > where it happens rather than where it's defined. > > IMO, the default should be to use the context

Re: [Python-ideas] PEP draft: context variables

On 15 October 2017 at 15:05, Guido van Rossum wrote: > I would like to reboot this discussion (again). It feels to me we're > getting farther and farther from solving any of the problems we might solve. > > I think we need to give up on doing anything about generators; the use

Re: [Python-ideas] PEP draft: context variables

On 15.10.2017 06:39, Nick Coghlan wrote: > On 15 October 2017 at 05:47, Paul Moore > wrote: > > On 14 October 2017 at 17:50, Nick Coghlan > wrote: > > If you capture the context

Re: [Python-ideas] PEP draft: context variables

On 15 October 2017 at 14:53, M.-A. Lemburg wrote: > On 15.10.2017 06:39, Nick Coghlan wrote: > > On 15 October 2017 at 05:47, Paul Moore > > wrote: > > > > On 14 October 2017 at 17:50, Nick Coghlan >

Re: [Python-ideas] PEP draft: context variables

I would like to reboot this discussion (again). It feels to me we're getting farther and farther from solving any of the problems we might solve. I think we need to give up on doing anything about generators; the use cases point in too many conflicting directions. So we should keep the semantics

Re: [Python-ideas] PEP draft: context variables

On 15 October 2017 at 05:47, Paul Moore wrote: > On 14 October 2017 at 17:50, Nick Coghlan wrote: > > If you capture the context eagerly, then there are fewer opportunities to > > get materially different values from "data = list(iterable)" and "data = >

Re: [Python-ideas] PEP draft: context variables

On 14 October 2017 at 17:50, Nick Coghlan wrote: > On 14 October 2017 at 21:56, Paul Moore wrote: > > TL;DR of below: PEP 550 currently gives you what you're after, so your > perspective counts as a preference for "please don't eagerly capture the >

Re: [Python-ideas] PEP draft: context variables

On 14 October 2017 at 21:56, Paul Moore wrote: TL;DR of below: PEP 550 currently gives you what you're after, so your perspective counts as a preference for "please don't eagerly capture the creation time context in generators or coroutines". To give an example: > >

Re: [Python-ideas] PEP draft: context variables

On 14 October 2017 at 08:44, Steve Dower wrote: > > It's not possible to special case __aenter__ and __aexit__ reliably >> (supporting wrappers, decorators, and possible side effects). >> > > Why not? Can you not add a decorator that sets a flag on the code object > that

Re: [Python-ideas] PEP draft: context variables

really like what Paul Moore wrote here as it matches a *LOT* of what I have been feeling as I have been reading this whole discussion; specifically: - I find the example, and discussion, really hard to follow. - I also, don't understand async, but I do understand generators very

Re: [Python-ideas] PEP draft: context variables

On 10/13/2017 03:30 PM, Yury Selivanov wrote: At this time, we have so many conflicted examples and tangled discussions on these topics, that I myself just lost what everybody is implying by "this semantics isn't obvious to *me*". Which semantics? It's hard to tell. For me, it's not apparent

Re: [Python-ideas] PEP draft: context variables

On 13Oct2017 1132, Yury Selivanov wrote: On Fri, Oct 13, 2017 at 1:45 PM, Ethan Furman wrote: On 10/13/2017 09:48 AM, Steve Dower wrote: On 13Oct2017 0941, Yury Selivanov wrote: Actually, capturing context at the moment of coroutine creation (in PEP 550 v1 semantics)

Re: [Python-ideas] PEP draft: context variables

On 13 October 2017 at 19:32, Yury Selivanov wrote: >>> It seems simpler to have one specially named and specially called function >>> be special, rather than make the semantics >>> more complicated for all functions. >> > > It's not possible to special case __aenter__ and

Re: [Python-ideas] PEP draft: context variables

On Fri, Oct 13, 2017 at 1:45 PM, Ethan Furman wrote: > On 10/13/2017 09:48 AM, Steve Dower wrote: >> >> On 13Oct2017 0941, Yury Selivanov wrote: > > >>> Actually, capturing context at the moment of coroutine creation (in >>> PEP 550 v1 semantics) will not work at all. Async

Re: [Python-ideas] PEP draft: context variables

On Fri, Oct 13, 2017 at 8:45 PM, Ethan Furman wrote: > On 10/13/2017 09:48 AM, Steve Dower wrote: > >> On 13Oct2017 0941, Yury Selivanov wrote: >> > > Actually, capturing context at the moment of coroutine creation (in >>> PEP 550 v1 semantics) will not work at all. Async

Re: [Python-ideas] PEP draft: context variables

On 10/13/2017 09:48 AM, Steve Dower wrote: On 13Oct2017 0941, Yury Selivanov wrote: Actually, capturing context at the moment of coroutine creation (in PEP 550 v1 semantics) will not work at all. Async context managers will break. class AC: async def __aenter__(self):

Re: [Python-ideas] PEP draft: context variables

On Fri, Oct 13, 2017 at 2:07 AM, Stefan Krah wrote: [..] > So the decimal examples can be helpful for understanding, but (except > for the performance issues) shouldn't be the centerpiece of the > discussion. > > > Speaking of performance, I have seen that adressed in Koos'

Re: [Python-ideas] PEP draft: context variables

On 13Oct2017 0941, Yury Selivanov wrote: On Fri, Oct 13, 2017 at 3:25 AM, Nick Coghlan wrote: [..] However, considering that coroutines are almost always instantiated at the point where they're awaited, I do concede that creation time context capture would likely also work

Re: [Python-ideas] PEP draft: context variables

On Fri, Oct 13, 2017 at 3:25 AM, Nick Coghlan wrote: [..] > However, considering that coroutines are almost always instantiated at the > point where they're awaited, I do concede that creation time context capture > would likely also work out OK for the coroutine case, which

Re: [Python-ideas] PEP draft: context variables

On Fri, Oct 13, 2017 at 3:25 AM, Nick Coghlan wrote: [..] > The rationale for this behaviour *does* arise from a refactoring argument: > >async def original_async_function(): > with some_context(): > do_some_setup() > raw_data = await

Re: [Python-ideas] PEP draft: context variables

On 13 October 2017 at 10:56, Guido van Rossum wrote: > I'm out of energy to debate every point (Steve said it well -- that > decimal/generator example is too contrived), but I found one nit in Nick's > email that I wish to correct. > > On Wed, Oct 11, 2017 at 1:28 AM, Nick

Re: [Python-ideas] PEP draft: context variables

I'm out of energy to debate every point (Steve said it well -- that decimal/generator example is too contrived), but I found one nit in Nick's email that I wish to correct. On Wed, Oct 11, 2017 at 1:28 AM, Nick Coghlan wrote: > > As a less-contrived example, consider context

[Python-ideas] PEP draft: context variables

Yury Selivanov wrote: [generators and decimal] > Specifically for decimal: I tried to find bug reports on > bugs.python.org (found not even one), questions on stackoverflow (IIRC > I didn't find anything), and used github code search and google > (again, nothing directly relevant). I also

Re: [Python-ideas] PEP draft: context variables

> Although it is true that I plan to propose to use PEP 550 to > reimplement decimal APIs on top of it, and so far I haven't seen any > real-world examples of code that will be broken because of that. As > far as I know—and I've done some research—nobody uses decimal contexts > > and generators

Re: [Python-ideas] PEP draft: context variables

On Oct 12, 2017 9:03 PM, "Yury Selivanov" wrote: On Thu, Oct 12, 2017 at 8:59 AM, Koos Zevenhoven wrote: > On Thu, Oct 12, 2017 at 6:54 AM, Nick Coghlan wrote: [..] >> 1. Preserve the current behaviour, since we don't have a

Re: [Python-ideas] PEP draft: context variables

On Thu, Oct 12, 2017 at 6:54 AM, Nick Coghlan wrote: > On 11 October 2017 at 21:58, Koos Zevenhoven wrote: > >> On Wed, Oct 11, 2017 at 7:46 AM, Steve Dower >> wrote: >> >>> Nick: “I like Yury's example for this, which is that the

Re: [Python-ideas] PEP draft: context variables

On 11Oct2017 0458, Koos Zevenhoven wrote: ​Exactly. You did say it less politely than I did, but this is exactly how I thought about it. And I'm not sure people got it the first time. Yes, perhaps a little harsh. However, if I released a refactoring tool that moved function calls that far,

Re: [Python-ideas] PEP draft: context variables

On Wed, Oct 11, 2017 at 7:46 AM, Steve Dower wrote: > Nick: “I like Yury's example for this, which is that the following two > examples are currently semantically equivalent, and we want to preserve > that equivalence: > > > > with decimal.localcontext() as ctx: > >

Re: [Python-ideas] PEP draft: context variables

On 11 October 2017 at 02:52, Guido van Rossum wrote: > I think we really need to do more soul-searching before we decide that a > much more complex semantics and implementation is worth it to maintain > backwards compatibility for leaking in via next(). > As a less-contrived

Re: [Python-ideas] PEP draft: context variables

certainly a feature that I want for myself more than I want another spelling for TLS…) Top-posted from my Windows phone From: Nick Coghlan Sent: Tuesday, October 10, 2017 5:35 To: Guido van Rossum Cc: Python-Ideas Subject: Re: [Python-ideas] PEP draft: context variables On 10 October 2017 at 01:24

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 5:34 AM, Nick Coghlan wrote: > On 10 October 2017 at 01:24, Guido van Rossum wrote: > >> On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan wrote: >> >>> On 8 October 2017 at 08:40, Koos Zevenhoven

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 12:34 PM, Koos Zevenhoven wrote: > On Tue, Oct 10, 2017 at 3:42 PM, Nick Coghlan wrote: [..] >> Context managers are merely syntactic sugar for try/finally statements, so >> you can't wave your hands and say a context manager is the

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 12:21 PM, Koos Zevenhoven wrote: [..] >> Please stop using "many things .. would", "most likely" etc. > > > I can't explain everything, especially not in a single email. I will use > whatever English words I need. You can also think for yourself––or ask

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 11:26 AM, Koos Zevenhoven wrote: > On Tue, Oct 10, 2017 at 5:40 PM, Yury Selivanov > wrote: >> >> On Tue, Oct 10, 2017 at 8:34 AM, Koos Zevenhoven >> wrote: >> > On Tue, Oct 10, 2017 at 4:22 AM, Yury

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 5:46 PM, Yury Selivanov wrote: > On Tue, Oct 10, 2017 at 10:22 AM, Koos Zevenhoven > wrote: > > On Tue, Oct 10, 2017 at 5:01 PM, Nick Coghlan > wrote: > >> > >> On 10 October 2017 at 22:51, Koos Zevenhoven

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 5:40 PM, Yury Selivanov wrote: > On Tue, Oct 10, 2017 at 8:34 AM, Koos Zevenhoven > wrote: > > On Tue, Oct 10, 2017 at 4:22 AM, Yury Selivanov > > > wrote: > >> > >> On Mon, Oct 9, 2017 at 8:37 PM,

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 10:22 AM, Koos Zevenhoven wrote: > On Tue, Oct 10, 2017 at 5:01 PM, Nick Coghlan wrote: >> >> On 10 October 2017 at 22:51, Koos Zevenhoven wrote: >>> >>> I see no reason why these two should be equivalent. >> >>

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 8:34 AM, Koos Zevenhoven wrote: > On Tue, Oct 10, 2017 at 4:22 AM, Yury Selivanov > wrote: >> >> On Mon, Oct 9, 2017 at 8:37 PM, Koos Zevenhoven wrote: >> > You can cause unbound growth in PEP 550 too. All

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 5:01 PM, Nick Coghlan wrote: > On 10 October 2017 at 22:51, Koos Zevenhoven wrote: > >> ​I see no reason why these two should be equivalent. >> > > There is no "should" about it: it's a brute fact that the two forms *are* >

Re: [Python-ideas] PEP draft: context variables

On 10 October 2017 at 22:51, Koos Zevenhoven wrote: > ​I see no reason why these two should be equivalent. > There is no "should" about it: it's a brute fact that the two forms *are* currently equivalent for lazy iterators (including generators), and both different from the

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 3:34 PM, Nick Coghlan wrote: > On 10 October 2017 at 01:24, Guido van Rossum wrote: > >> On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan wrote: >> >>> On 8 October 2017 at 08:40, Koos Zevenhoven

Re: [Python-ideas] PEP draft: context variables

On 10 October 2017 at 22:34, Koos Zevenhoven wrote: > Really, it was my mistake to ever make you think that > context_var.assign(42).__enter__() can be compared to .set(42) in PEP > 550. I'll say it once more: PEP 555 context arguments have no equivalent of > the PEP-550

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 4:22 AM, Yury Selivanov wrote: > On Mon, Oct 9, 2017 at 8:37 PM, Koos Zevenhoven wrote: > > You can cause unbound growth in PEP 550 too. All you have to do is nest > an > > unbounded number of generators. > > You can only nest

Re: [Python-ideas] PEP draft: context variables

On 10 October 2017 at 01:24, Guido van Rossum wrote: > On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan wrote: > >> On 8 October 2017 at 08:40, Koos Zevenhoven wrote: >> >>> ​​I do remember Yury mentioning that the first draft of PEP 550

Re: [Python-ideas] PEP draft: context variables

On Mon, Oct 9, 2017 at 8:37 PM, Koos Zevenhoven wrote: [..] >> Another thing: suppose someone calls >> 'context_var.assign().__enter__()' manually, without calling >> '__exit__()'. You will have unbound growth of the context values >> stack. > > > You can cause unbound growth

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 1:55 AM, Yury Selivanov wrote: > On Mon, Oct 9, 2017 at 4:39 PM, Koos Zevenhoven wrote: > > On Mon, Oct 9, 2017 at 6:24 PM, Guido van Rossum > wrote: > [..] > >> I'm not sure I agree on the usefulness.

Re: [Python-ideas] PEP draft: context variables

On Mon, Oct 9, 2017 at 4:39 PM, Koos Zevenhoven wrote: > On Mon, Oct 9, 2017 at 6:24 PM, Guido van Rossum wrote: [..] >> I'm not sure I agree on the usefulness. Certainly a lot of the complexity >> of PEP 550 exists just to cater to Nathaniel's desire to

Re: [Python-ideas] PEP draft: context variables

On Mon, Oct 9, 2017 at 6:24 PM, Guido van Rossum wrote: > On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan wrote: > >> On 8 October 2017 at 08:40, Koos Zevenhoven wrote: >> >>> On Sun, Oct 8, 2017 at 12:16 AM, Nathaniel Smith

Re: [Python-ideas] PEP draft: context variables

On Mon, Oct 9, 2017 at 9:46 AM, Nick Coghlan wrote: > On 8 October 2017 at 08:40, Koos Zevenhoven wrote: > >> On Sun, Oct 8, 2017 at 12:16 AM, Nathaniel Smith wrote: >> >>> On Oct 7, 2017 12:20, "Koos Zevenhoven" wrote:

Re: [Python-ideas] PEP draft: context variables

On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan wrote: > On 8 October 2017 at 08:40, Koos Zevenhoven wrote: > >> On Sun, Oct 8, 2017 at 12:16 AM, Nathaniel Smith wrote: >> >>> On Oct 7, 2017 12:20, "Koos Zevenhoven"

Re: [Python-ideas] PEP draft: context variables

On 8 October 2017 at 08:40, Koos Zevenhoven wrote: > On Sun, Oct 8, 2017 at 12:16 AM, Nathaniel Smith wrote: > >> On Oct 7, 2017 12:20, "Koos Zevenhoven" wrote: >> >> >> ​Unfortunately, we actually need a third kind of generator semantics,

Re: [Python-ideas] PEP draft: context variables

On Sun, Oct 8, 2017 at 12:16 AM, Nathaniel Smith wrote: > On Oct 7, 2017 12:20, "Koos Zevenhoven" wrote: > > > ​Unfortunately, we actually need a third kind of generator semantics, > something like this: > > @​contextvars.caller_context > def genfunc(): >

Re: [Python-ideas] PEP draft: context variables

On Oct 7, 2017 12:20, "Koos Zevenhoven" wrote: ​Unfortunately, we actually need a third kind of generator semantics, something like this: @​contextvars.caller_context def genfunc(): assert cvar.value is the_value yield assert cvar.value is the_value with

Re: [Python-ideas] PEP draft: context variables

Hi all, Thank you for the feedback so far. FYI, or as a reminder, this is now PEP 555, but the web version is still the same draft that I posted here. ​The discussion of this was paused as there was a lot going on at that moment, but I'm now getting ready to make a next version of the draft.​

Re: [Python-ideas] PEP draft: context variables

Hi!, > Core concept > > > A context-local variable is represented by a single instance of > ``contextvars.Var``, say ``cvar``. Any code that has access to the ``cvar`` > object can ask for its value with respect to the current context. In the > high-level API, this value is given by

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 10:54 AM Guido van Rossum wrote: > On Tue, Sep 5, 2017 at 7:42 AM, Neil Girdhar > wrote: > >> I think you really should add a context manager to PEP 550 since it is >> better than calling "set", which leaks state. Nathaniel is

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 8:43 PM, Yury Selivanov wrote: > On Tue, Sep 5, 2017 at 10:31 AM, Koos Zevenhoven > wrote: > > On Tue, Sep 5, 2017 at 8:24 PM, Yury Selivanov > > wrote: > >> > >> I don't actually care if you use the

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 10:31 AM, Koos Zevenhoven wrote: > On Tue, Sep 5, 2017 at 8:24 PM, Yury Selivanov > wrote: >> >> On Tue, Sep 5, 2017 at 9:12 AM, Koos Zevenhoven wrote: >> > On Tue, Sep 5, 2017 at 6:53 PM, Yury Selivanov

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 8:24 PM, Yury Selivanov wrote: > On Tue, Sep 5, 2017 at 9:12 AM, Koos Zevenhoven wrote: > > On Tue, Sep 5, 2017 at 6:53 PM, Yury Selivanov > > wrote: > >> > >> On Tue, Sep 5, 2017 at 8:35 AM, Koos

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 9:12 AM, Koos Zevenhoven wrote: > On Tue, Sep 5, 2017 at 6:53 PM, Yury Selivanov > wrote: >> >> On Tue, Sep 5, 2017 at 8:35 AM, Koos Zevenhoven wrote: >> > On Tue, Sep 5, 2017 at 3:49 AM, Nathaniel Smith

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 3:49 AM, Nathaniel Smith wrote: > On Mon, Sep 4, 2017 at 2:50 PM, Koos Zevenhoven wrote: > > Hi all, > > > > as promised, here is a draft PEP for context variable semantics and > > implementation. Apologies for the slight delay; I had a

Re: [Python-ideas] PEP draft: context variables

We'll add a reference to the "Can Execution Context be implemented without modifying CPython?" section [1]. However, after skimming through the readme file, I didn't see any examples or limitations that are relevant to PEP 550. If the PEP gets accepted, Twisted can simply add direct support for

Re: [Python-ideas] PEP draft: context variables

I am a relative nobody in Python, however a few weeks ago, I suggested more harmonization with JavaScript. Admittedly I've been doing more JS lately, so I might have JS-colored glasses on, but it looks like you're trying to add lexical scoping to Python, and there's a whole lot of manual scope

Re: [Python-ideas] PEP draft: context variables

You should add https://bitbucket.org/hipchat/txlocal as a reference for the pep as it largely implements this idea for Twisted. It may provide for some practical discussions of use cases and limitations of this approach. On Tue, Sep 5, 2017, 09:55 Guido van Rossum wrote: > On

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 7:42 AM, Neil Girdhar wrote: > I think you really should add a context manager to PEP 550 since it is > better than calling "set", which leaks state. Nathaniel is right that you > need set to support legacy numpy methods like seterr. Had there been

Re: [Python-ideas] PEP draft: context variables

On Monday, September 4, 2017 at 6:37:44 PM UTC-4, Yury Selivanov wrote: > > So every generator stores "captured" modifications. This is similar > to PEP 550, which adds Logical Context to generators to store their EC > modifications. The implementation is different, but the intent is the >

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 1:20 AM, Oleg Broytman wrote: > Hi! > > On Tue, Sep 05, 2017 at 12:50:35AM +0300, Koos Zevenhoven < > k7ho...@gmail.com> wrote: > > cvar = contextvars.Var(default="the default value", > >description="example context

Re: [Python-ideas] PEP draft: context variables

On 9/4/17, Koos Zevenhoven wrote: > Core concept > > > A context-local variable is represented by a single instance of > ``contextvars.Var``, say ``cvar``. Any code that has access to the ``cvar`` > object can ask for its value with respect to the current context.

Re: [Python-ideas] PEP draft: context variables

On Mon, Sep 4, 2017 at 2:50 PM, Koos Zevenhoven wrote: > Hi all, > > as promised, here is a draft PEP for context variable semantics and > implementation. Apologies for the slight delay; I had a not-so-minor > autosave accident and had to retype the majority of this first

Re: [Python-ideas] PEP draft: context variables

So every generator stores "captured" modifications. This is similar to PEP 550, which adds Logical Context to generators to store their EC modifications. The implementation is different, but the intent is the same. PEP 550 uses a stack of hash tables, this proposal has a linked list of

Re: [Python-ideas] PEP draft: context variables

Hi! On Tue, Sep 05, 2017 at 12:50:35AM +0300, Koos Zevenhoven wrote: > cvar = contextvars.Var(default="the default value", >description="example context variable") Why ``description`` and not ``doc``? > with cvar.assign(new_value):

[Python-ideas] PEP draft: context variables

Hi all, as promised, here is a draft PEP for context variable semantics and implementation. Apologies for the slight delay; I had a not-so-minor autosave accident and had to retype the majority of this first draft. During the past years, there has been growing interest in something like