On 4 January 2018 at 00:17, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> contextvars.copy_context().run(func, )
>
>
> If contexts are immutable, why is there something
> called copy_context?
Agreed. This was something that bothered me, too. I mentioned it in my
review, but that seemed to get
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
On Thu, Jan 4, 2018 at 3:25 AM, Paul Moore wrote:
> On 4 January 2018 at 00:17, Greg Ewing
> wrote:
> > Guido van Rossum wrote:
> >>
> >> contextvars.copy_context().run(func, )
> >
> > If contexts are immutable, why is there something
> > called copy_context?
>
> Agreed. This was something that
On 4 January 2018 at 15:56, Guido van Rossum wrote:
> It was get_context() in an earlier version of PEP 567. We changed it to
> copy_context() believing that that would clarify that you get a clone that
> is unaffected by subsequent ContextVar.set() operations (which affect the
> *current* context
On Wed, Jan 3, 2018 at 6:35 PM, Nathaniel Smith wrote:
> On Wed, Jan 3, 2018 at 3:44 PM, Victor Stinner
> wrote:
> > Ok, I finally got access to a computer and I was able to test the PEP
> > 567 implementation: see my code snippet below.
> >
> > The behaviour is more tricky than what I expected.
On Thu, Jan 4, 2018 at 8:30 AM, Guido van Rossum wrote:
> On Wed, Jan 3, 2018 at 6:35 PM, Nathaniel Smith wrote:
>> - Context is a mutable object representing a mapping
>> - BUT it doesn't allow mutation through the MutableMapping interface;
>> instead, the only way to mutate it is by calling Con
Guido van Rossum wrote:
It was get_context() in an earlier version of PEP 567. We changed it to
copy_context() believing that that would clarify that you get a clone
that is unaffected by subsequent ContextVar.set() operations (which
affect the *current* context rather than the copy you just go
On Thu, Jan 4, 2018 at 9:27 AM, Paul Moore wrote:
> On 4 January 2018 at 15:56, Guido van Rossum wrote:
> > It was get_context() in an earlier version of PEP 567. We changed it to
> > copy_context() believing that that would clarify that you get a clone
> that
> > is unaffected by subsequent Con
On Thu, Jan 4, 2018 at 4:56 PM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> It was get_context() in an earlier version of PEP 567. We changed it to
>> copy_context() believing that that would clarify that you get a clone that
>> is unaffected by subsequent ContextVar.set() operations (which
Your suggestions sound reasonable, but we are now running into a logistical
problem -- I don't want to decide this unilaterally but Yury is on vacation
until Jan 15. That gives us at most 2 weeks for approval of the PEP and
review + commit of the implementation (
https://github.com/python/cpython/p
We should interview you for the paper we may be writing for HOPL.
On Wed, Jan 3, 2018 at 6:05 PM, Neil Schemenauer
wrote:
> On 2018-01-03, Guido van Rossum wrote:
> > I'm sorry, I don't think more research can convince me either way.
> > I want all three of return/break/continue to work inside f
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 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 Tue, Jan 2, 2018 at 4:30 PM, Victor Stinner
wrote:
> Hum, it seems like the specification (API) part of the PEP is polluted by
> its implementation. The PEP just require a few minor changes to better
> describe the behaviour/API instead of insisting on the read only internal
> thing which is s
On Thu, Jan 4, 2018 at 6:09 PM, Guido van Rossum wrote:
> However you've not convinced me that it would be better to make Context
> implement the full MutableMapping interface (with `__delitem__` always
> raising). There are use cases for inspecting Context, e.g. a debugger that
> wants to print t
Guido van Rossum wrote:
Well, it's not *immutable* (it shouldn't support hash()), but it doesn't
follow the MutableMapping protocol -- it only follows the Mapping
protocol.
That's why I wrote "mapping" with a small "m". If there's
a better term for "collection of associations between keys
and
On 2018-01-04, Guido van Rossum wrote:
> We should interview you for the paper we may be writing for HOPL.
History of Programming Languages?
I did some more digging this afternoon, trying to find source code
between versions 1.0.1 and 0.9.1. No luck though. It looks like
0.9.1 might have been t
On Thu, Jan 4, 2018 at 7:58 PM, Nathaniel Smith wrote:
> On Thu, Jan 4, 2018 at 6:09 PM, Guido van Rossum wrote:
> > However you've not convinced me that it would be better to make Context
> > implement the full MutableMapping interface (with `__delitem__` always
> > raising). There are use case
On 3 January 2018 at 06:35, Barry Warsaw wrote:
> Brett doesn’t like this, for several reasons (quoting):
>
> 1. redundant API in all cases where the loader is unique to the module
> 2. the memory savings of sharing a loader is small
> 3. it's implementation complexity/overhead for an optimization
19 matches
Mail list logo
