On Mon, Dec 18, 2017 at 8:37 PM Yury Selivanov
wrote:
> > 3. The connection pool has a queue, and creates a task for each
> connection to serve requests from that queue. Naively, each task could
> inherit the context of the request that caused it to be created, but the
> task would outlive the re
On Sun, Dec 17, 2017 at 2:49 PM Yury Selivanov
wrote:
> > One caveat based on Tornado's experience with stack_context: There are
> times
> > when the automatic propagation of contexts won't do the right thing (for
> > example, a database client with a connection pool may end up hanging on
> to
>
On Mon, Dec 18, 2017 at 6:00 PM, Ivan Levkivskyi wrote:
> On 13 December 2017 at 22:35, Yury Selivanov
> wrote:
>>
>> [..]
>> >> A new standard library module ``contextvars`` is added
>> >
>> > Why not add this to contextlib instead of adding a new module? IIRC
>> > this was discussed relative t
> 3. The connection pool has a queue, and creates a task for each connection to
> serve requests from that queue. Naively, each task could inherit the context
> of the request that caused it to be created, but the task would outlive the
> request and go on to serve other requests. The connection
On 13 December 2017 at 22:35, Yury Selivanov
wrote:
> [..]
> >> A new standard library module ``contextvars`` is added
> >
> > Why not add this to contextlib instead of adding a new module? IIRC
> > this was discussed relative to PEP 550, but I don't remember the
> > reason. Regardless, it woul
Hi Ben,
On Sun, Dec 17, 2017 at 10:38 AM, Ben Darnell wrote:
> On Tue, Dec 12, 2017 at 12:34 PM Yury Selivanov
> wrote:
>>
>> Hi,
>>
>> This is a new proposal to implement context storage in Python.
>>
>> It's a successor of PEP 550 and builds on some of its API ideas and
>> datastructures. Con
On Tue, Dec 12, 2017 at 12:34 PM Yury Selivanov
wrote:
> Hi,
>
> This is a new proposal to implement context storage in Python.
>
> It's a successor of PEP 550 and builds on some of its API ideas and
> datastructures. Contrary to PEP 550 though, this proposal only focuses
> on adding new APIs an
Hi Eric,
Thanks for a detailed review!
On Wed, Dec 13, 2017 at 3:59 PM, Eric Snow wrote:
> Overall, I like this PEP. It's definitely easier to follow
> conceptually than PEP 550. Thanks for taking the time to re-think the
> idea. I have a few comments in-line below.
>
> -eric
>
> On Tue, Dec
On Tue, Dec 12, 2017 at 4:49 PM, Victor Stinner
wrote:
>> The ``Token`` API exists to make the current proposal forward
>> compatible with :pep:`550`, in case there is demand to support
>> context variables in generators and asynchronous generators in the
>> future.
>
> Cool. I like the idea of st
Overall, I like this PEP. It's definitely easier to follow
conceptually than PEP 550. Thanks for taking the time to re-think the
idea. I have a few comments in-line below.
-eric
On Tue, Dec 12, 2017 at 10:33 AM, Yury Selivanov
wrote:
> This is a new proposal to implement context storage in Py
Hi Dima,
2017-12-13 7:39 GMT+01:00 Dima Tisnek :
> get()/set(value)/delete() methods: Python provides syntax sugar for
> these, let's use it.
> (dict: d["k"]/d["k] = value/del d["k"]; attrs: obj.k/obj.k = value/del
> obj.k; inheriting threading.Local)
I was trapped by Context which is described a
On Tue, Dec 12, 2017 at 10:39 PM, Dima Tisnek wrote:
> My 2c:
> TL;DR PEP specifies implementation in some detail, but doesn't show
> how proposed change can or should be used.
>
>
>
> get()/set(value)/delete() methods: Python provides syntax sugar for
> these, let's use it.
> (dict: d["k"]/d["k]
My 2c:
TL;DR PEP specifies implementation in some detail, but doesn't show
how proposed change can or should be used.
get()/set(value)/delete() methods: Python provides syntax sugar for
these, let's use it.
(dict: d["k"]/d["k] = value/del d["k"]; attrs: obj.k/obj.k = value/del
obj.k; inheriting
On Tue, Dec 12, 2017 at 10:36 PM, Guido van Rossum wrote:
> Some more feedback:
>
>> This proposal builds directly upon concepts originally introduced
>> in :pep:`550`.
>
> The phrase "builds upon" typically implies that the other resource must be
> read and understood first. I don't think that we
Some more feedback:
> This proposal builds directly upon concepts originally introduced
> in :pep:`550`.
The phrase "builds upon" typically implies that the other resource must be
read and understood first. I don't think that we should require PEP 550 for
understanding of PEP 567. Maybe "This pro
On Tue, Dec 12, 2017 at 9:55 PM, Guido van Rossum wrote:
> On Tue, Dec 12, 2017 at 5:35 PM, Yury Selivanov
> wrote:
>>
>> On Tue, Dec 12, 2017 at 6:49 PM, Victor Stinner
>> wrote:
>> > I like the overall idea and I prefer this PEP over PEP 550 since it's
>> > shorter and easier to read :-)
>> >
On Tue, Dec 12, 2017 at 5:35 PM, Yury Selivanov
wrote:
> On Tue, Dec 12, 2017 at 6:49 PM, Victor Stinner
> wrote:
> > I like the overall idea and I prefer this PEP over PEP 550 since it's
> > shorter and easier to read :-)
> >
> > Question: Is there an API to list all context variables?
>
> Cont
Hi Victor,
On Tue, Dec 12, 2017 at 6:49 PM, Victor Stinner
wrote:
> Hi Yury,
>
> I like the overall idea and I prefer this PEP over PEP 550 since it's
> shorter and easier to read :-)
>
> Question: Is there an API to list all context variables?
Context implements abc.Mapping, so 'get_context().k
Hi Yury,
I like the overall idea and I prefer this PEP over PEP 550 since it's
shorter and easier to read :-)
Question: Is there an API to list all context variables?
Would it be possible to have a very summary of the changes in the PEP?
I propose:
"""
* Added contextvars module with ContextVar
Hi,
This is a new proposal to implement context storage in Python.
It's a successor of PEP 550 and builds on some of its API ideas and
datastructures. Contrary to PEP 550 though, this proposal only focuses
on adding new APIs and implementing support for it in asyncio. There
are no changes to th
20 matches
Mail list logo
