On Mon, 21 Aug 2017 01:45:05 -0400
"Jim J. Jewett" wrote:
> Building on Brett's suggestion:
>
> FrameContext: used in/writable by one frame
It's not frame-specific, it's actually shared by an arbitrary number of
frames (by default, all frames in a given thread).
Regards
Antoine.
On 21 August 2017 at 15:03, Guido van Rossum wrote:
> Honestly I'm not sure we need the distinction between LC and EC. If you read
> carefully some of the given example code seems to confuse them. If we could
> get away with only a single framework-facing concept, I would be happy
> calling it Exe
On 08/21/2017 04:43 AM, Antoine Pitrou wrote:
On Mon, 21 Aug 2017 01:45:05 -0400
"Jim J. Jewett" wrote:
Building on Brett's suggestion:
FrameContext: used in/writable by one frame
It's not frame-specific, it's actually shared by an arbitrary number of
frames (by default, all frames in a
-1 on using "frame" in PEP 550 terminology. Antoine is right, the API
is not frame-specific, and "frame" in Python has only one meaning.
I can certainly see how "ContextFrame" can be correct if we think
about "frame" as a generic term, but in Python, people will
inadvertently think about a connect
On Mon, Aug 21, 2017 at 7:12 AM, Nick Coghlan wrote:
> On 21 August 2017 at 15:03, Guido van Rossum wrote:
> > Honestly I'm not sure we need the distinction between LC and EC. If you
> read
> > carefully some of the given example code seems to confuse them. If we
> could
> > get away with only a
On Mon, Aug 21, 2017 at 3:10 PM, Guido van Rossum wrote:
[..]
> Agreed. However now I am confused as to how the HAMT fits in. Yury says
> somewhere that the HAMT will be used for the EC and then cloning the EC is
> just returning a pointer to the same EC. But even if I interpret that as
> making a
On Sat, Aug 19, 2017 at 4:17 AM, Nick Coghlan wrote:
[..]
>>
>> * Generator's ``.send()`` and ``.throw()`` methods are modified as
>> follows (in pseudo-C)::
>>
>> if gen.__logical_context__ is not NULL:
>> tstate = PyThreadState_Get()
>>
>> tstate.execution_context.push(gen.
On Mon, Aug 21, 2017 at 5:12 PM, Nick Coghlan wrote:
> On 21 August 2017 at 15:03, Guido van Rossum wrote:
> > Honestly I'm not sure we need the distinction between LC and EC. If you
> read
> > carefully some of the given example code seems to confuse them. If we
> could
> > get away with only a
On Mon, Aug 21, 2017 at 5:14 PM, Koos Zevenhoven wrote:
[..]
>> This has consequences for the design in the PEP:
>>
>> * what we want to capture at generator creation time is the context
>> where writes will happen, and we also want that to be the innermost
>> context used for lookups
>
>
> I don'
On Tue, Aug 22, 2017 at 12:25 AM, Yury Selivanov
wrote:
> On Mon, Aug 21, 2017 at 5:14 PM, Koos Zevenhoven
> wrote:
> [..]
> >> This has consequences for the design in the PEP:
> >>
> >> * what we want to capture at generator creation time is the context
> >> where writes will happen, and we als
On Mon, Aug 21, 2017 at 5:39 PM, Koos Zevenhoven wrote:
[..]
>> In the current version of the PEP, generators are initialized with an
>> empty LogicalContext. When they are being iterated (started or
>> resumed), their LogicalContext is pushed to the EC. When the
>> iteration is stopped (or paus
Yury Selivanov wrote:
I can certainly see how "ContextFrame" can be correct if we think
about "frame" as a generic term, but in Python, people will
inadvertently think about a connection with frame objects/stacks.
Calling it ExecutionContextFrame rather than just ContextFrame
would make it clea
On Mon, Aug 21, 2017 at 12:50 PM, Yury Selivanov
wrote:
> Few important things (using the current PEP 550 terminology):
>
> * ExecutionContext is a *dynamic* stack of LogicalContexts.
> * LCs do not reference other LCs.
> * ContextKey.set() can only modify the *top* LC in the stack.
>
> If LC is
On Mon, Aug 21, 2017 at 8:06 PM, Guido van Rossum wrote:
> On Mon, Aug 21, 2017 at 12:50 PM, Yury Selivanov
> wrote:
>>
>> Few important things (using the current PEP 550 terminology):
>>
>> * ExecutionContext is a *dynamic* stack of LogicalContexts.
>> * LCs do not reference other LCs.
>> * Cont
On Mon, Aug 21, 2017 at 8:06 PM, Guido van Rossum wrote:
[..]
>> > OK, this really needs to be made very clear early in the PEP. Maybe this
>> > final sentence provides the key requirement: changes outside the
>> > generator
>> > should make it into the generator when next() is invoked, unless the
Ethan Furman wrote:
So I like ExecutionContext for the stack of
WhateverWeCallTheOtherContext contexts. But what do we call it?
How about ExecutionContextFrame, by analogy with stack/stack frame.
--
Greg
___
Python-Dev mailing list
Python-Dev@pytho
On 22 August 2017 at 09:39, Greg Ewing wrote:
> Ethan Furman wrote:
>>
>> So I like ExecutionContext for the stack of WhateverWeCallTheOtherContext
>> contexts. But what do we call it?
>
> How about ExecutionContextFrame, by analogy with stack/stack frame.
My latest suggestion to Yury was to see
On 22 August 2017 at 10:02, Greg Ewing wrote:
> Yury Selivanov wrote:
>>
>> I can certainly see how "ContextFrame" can be correct if we think
>> about "frame" as a generic term, but in Python, people will
>> inadvertently think about a connection with frame objects/stacks.
>
> Calling it Execution
On Tue, Aug 22, 2017 at 12:44 AM, Yury Selivanov
wrote:
> On Mon, Aug 21, 2017 at 5:39 PM, Koos Zevenhoven
> wrote:
> [..]
> >> In the current version of the PEP, generators are initialized with an
> >> empty LogicalContext. When they are being iterated (started or
> >> resumed), their LogicalC
On Tue, Aug 22, 2017 at 2:06 AM, Koos Zevenhoven wrote:
[..]
>> There will be an optimization: if the LC is empty, we will push NULL
>> to the stack, thus avoiding the cost of allocating an object.
>>
> But if LCs are immutable, there needs to be only one empty-LC instance. That
> would avoid spec
20 matches
Mail list logo
