I think we should let the naming issue go for now, while Yury et al. are
rewriting the PEP. We'll revisit it after we're more comfortable with the
semantics.
On Thu, Aug 24, 2017 at 9:55 PM, Nick Coghlan wrote:
> On 25 August 2017 at 01:00, Guido van Rossum wrote:
> > It shouldn't be called a n
On 25 August 2017 at 01:00, Guido van Rossum wrote:
> It shouldn't be called a namespace unless the dominant access is via
> attributes.
That makes sense.
Since the main purpose of that part of the Python API is to offer an
opaque handle to where the context locals store their values,
something
On Thu, Aug 24, 2017 at 5:37 AM, Nick Coghlan wrote:
> Migrating a (variant of a) naming subthread from python-ideas over to
> here, does the following sound plausible to anyone else?:
>
> ContextLocal - read/write access API (via get()/set() methods)
> ContextLocalNamespace - active mappi
It shouldn't be called a namespace unless the dominant access is via
attributes.
On Thu, Aug 24, 2017 at 4:37 AM, Nick Coghlan wrote:
> On 24 August 2017 at 08:47, Ethan Furman wrote:
> >
> > ContextVars is actually a different name for LogicalContext. So it would
> > be:
> >
> > ExecutionCo
On 24 August 2017 at 08:47, Ethan Furman wrote:
>
> ContextVars is actually a different name for LogicalContext. So it would
> be:
>
> ExecutionContext = [ContextVars()[, ContextVars()[ ...]]]
>
> and you get the (thread.local similar) ContextVars by
>
> context_vars = sys.get_context_vars()
On Thu, Aug 24, 2017 at 1:22 AM, Nick Coghlan wrote:
> On 24 August 2017 at 02:19, Yury Selivanov wrote:
>> I think that "implicit context" is not an accurate description of what
>> LogicalContext is.
>>
>> "implicit context" only makes sense when we talk about decimal
>> context. For instance,
On 24 August 2017 at 02:19, Yury Selivanov wrote:
> I think that "implicit context" is not an accurate description of what
> LogicalContext is.
>
> "implicit context" only makes sense when we talk about decimal
> context. For instance, in:
>
> Decimal(1) + Decimal(2)
>
> decimal context is im
On Wed, 23 Aug 2017 14:27:55 -0400
Yury Selivanov wrote:
>
> Yeah.. I like TaskContext when it's applied to asynchronous code. It
> doesn't really work for generators because we never refer to
> generators as tasks.
>
> Out of what was proposed so far to replace Logical Context:
>
> 1. DynamicC
On 08/23/2017 12:17 PM, Yury Selivanov wrote:
How about ExecutionContext and ContextVars ?
We are already used to different levels of variables: global, local, non-local,
class. I think having variables tied to a Context, and having search flow back
to previous Contexts, would be easy to un
What about "CoroutineScope" or "CoroutineContext"?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> How about ExecutionContext and ContextVars ?
> We are already used to different levels of variables: global, local,
> non-local, class. I think having variables tied to a Context, and having
> search flow back to previous Contexts, would be easy to understand.
Yeah, I had this idea about Con
On Wed, Aug 23, 2017 at 2:47 PM, Guido van Rossum wrote:
> In favor of ImplicitContext is one point: it is indeed "implicit" if you
> compare it with the "explicit" way of passing state around, which would
> require an extra argument containing the state for any function that uses
> the state *or
On 08/23/2017 11:27 AM, Yury Selivanov wrote:
Out of what was proposed so far to replace Logical Context:
[...]
I don't think that replacing LogicalContext with any name in this list
will make any improvement.
How about ExecutionContext and ContextVars ?
We are already used to different lev
In favor of ImplicitContext is one point: it is indeed "implicit" if you
compare it with the "explicit" way of passing state around, which would
require an extra argument containing the state for any function that uses
the state *or calls a function that uses the state* (recursively).
On Wed, Aug
On Wed, Aug 23, 2017 at 12:56 PM, Antoine Pitrou wrote:
> On Wed, 23 Aug 2017 12:19:40 -0400
> Yury Selivanov wrote:
>> PEP 550 calls generators and asynchronous tasks as "logical threads",
>> and "logical context" stems directly from that notion.
>
> I wouldn't refer to a generator as a "thread"
On Wed, 23 Aug 2017 12:19:40 -0400
Yury Selivanov wrote:
> PEP 550 calls generators and asynchronous tasks as "logical threads",
> and "logical context" stems directly from that notion.
I wouldn't refer to a generator as a "thread" personally. A thread
essentially executes without intervention f
I think that "implicit context" is not an accurate description of what
LogicalContext is.
"implicit context" only makes sense when we talk about decimal
context. For instance, in:
Decimal(1) + Decimal(2)
decimal context is implicit. But this is "implicit" from the
standpoint of that code.
For the record, I'm starting to think that "implicit context" is a
reasonable name.
(in case anyone is interested in those 2 cents of mine :-))
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listin
On Tue, Aug 22, 2017 at 11:21 PM, Nick Coghlan wrote:
>
> As the original proponent of a Dynamic* naming scheme, I'll note that
> I eventually decided I didn't like it for the same reason I already
> didn't like naming schemes using either the word "local" or the word
> "frame": they all suggest a
On 23 August 2017 at 13:51, Guido van Rossum wrote:
> Regarding DynamicAnything, I certainly saw it and didn't like it -- the only
> place where I've ever seen dynamic scoping was in Emacs Lisp, and I believe
> was first shown to me as anti-pattern thirty years ago.
As the original proponent of a
On Tue, Aug 22, 2017 at 8:51 PM, Guido van Rossum wrote:
> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
>>
>> We could do worse than just plain Context and ContextStack, for that
>> matter.
>
>
> I worry that that's going to lead more people astray thinking this has
> something to do w
On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:
> We could do worse than just plain Context and ContextStack, for that
> matter.
>
I worry that that's going to lead more people astray thinking this has
something to do with contextlib, which it really doesn't (it's much more
closely relat
On Tue, Aug 22, 2017 at 8:22 AM, Guido van Rossum wrote:
> As I understand the key APIs and constraints of the proposal better, I'm
> leaning towards FooContext (LC) and FooContextStack (EC), for some value of
> Foo that I haven't determined yet. Perhaps the latter can be shortened to
> just Conte
On 2017-08-23 00:12, Greg Ewing wrote:
Guido van Rossum wrote:
Perhaps the latter can be
shortened to just ContextStack (since the Foo part can probably be
guessed from context. :-)
-0.9, if I saw something called ContextStack turn up in a traceback
I wouldn't necessarily jump to the conclusi
Guido van Rossum wrote:
Perhaps the latter can be
shortened to just ContextStack (since the Foo part can probably be
guessed from context. :-)
-0.9, if I saw something called ContextStack turn up in a traceback
I wouldn't necessarily jump to the conclusion that it was a stack
of FooContexts ra
On Mon, Aug 21, 2017 at 10:09 PM, Nick Coghlan wrote:
> My latest suggestion to Yury was to see how the PEP reads with it
> called ImplicitContext, such that:
>
> * the active execution context is a stack of implicit contexts
> * ContextKey.set() updates the innermost implicit context
> * Context
As I understand the key APIs and constraints of the proposal better, I'm
leaning towards FooContext (LC) and FooContextStack (EC), for some value of
Foo that I haven't determined yet. Perhaps the latter can be shortened to
just ContextStack (since the Foo part can probably be guessed from context.
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
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 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 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
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 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
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 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
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 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
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: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 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 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 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 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
-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 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
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 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.
Building on Brett's suggestion:
FrameContext: used in/writable by one frame
ContextStack: a FrameContext and its various fallbacks
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
>
> On Sun, Aug 20, 2017, 03:08 Antoine Pitrou wrote:
>
>> On Sat, 19 Aug 2017 17:21:03 -0700
>> Guido van Rossum wrote:
>> > The way we came to "logical context" was via "logical thread (of
>> control)",
>> > which is distinct from OS thread. But I think we might need to search
>> for
>> > anoth
On Sun, Aug 20, 2017, 03:08 Antoine Pitrou wrote:
> On Sat, 19 Aug 2017 17:21:03 -0700
> Guido van Rossum wrote:
> > The way we came to "logical context" was via "logical thread (of
> control)",
> > which is distinct from OS thread. But I think we might need to search for
> > another term...
>
>
Hi Yury,
On 08/18/2017 10:33 PM, Yury Selivanov wrote:
> * ``.get()`` method: return the current EC value for the context key.
> Context keys return ``None`` when the key is missing, so the method
> never fails.
Is the difference between `Key not found` and `value is None` important
here?
Tha
On Sat, 19 Aug 2017 17:21:03 -0700
Guido van Rossum wrote:
> The way we came to "logical context" was via "logical thread (of control)",
> which is distinct from OS thread. But I think we might need to search for
> another term...
Perhaps "task context"? A "task" might be a logical thread, OS th
On 08/19/2017 10:41 PM, Nick Coghlan wrote:
On 20 August 2017 at 10:21, Guido van Rossum wrote:
The way we came to "logical context" was via "logical thread (of control)",
which is distinct from OS thread. But I think we might need to search for
another term...
Right. Framing it in pragmatic
On 20 August 2017 at 10:21, Guido van Rossum wrote:
> The way we came to "logical context" was via "logical thread (of control)",
> which is distinct from OS thread. But I think we might need to search for
> another term...
Right. Framing it in pragmatic terms, the two entities that we're
attempt
The way we came to "logical context" was via "logical thread (of control)",
which is distinct from OS thread. But I think we might need to search for
another term...
On Aug 19, 2017 11:56 AM, "Ethan Furman" wrote:
> On 08/19/2017 01:40 AM, Antoine Pitrou wrote:
>
>> On Fri, 18 Aug 2017 16:33:27
On 08/19/2017 01:40 AM, Antoine Pitrou wrote:
On Fri, 18 Aug 2017 16:33:27 -0400 Yury Selivanov wrote:
There are a few open questions left, namely the terminology
and design of ContextKey API. On the former topic, I'm quite
happy with the latest version: Execution Context, Logical
Context, an
On Sat, Aug 19, 2017, 01:43 Antoine Pitrou wrote:
> On Fri, 18 Aug 2017 16:33:27 -0400
> Yury Selivanov wrote:
> >
> > There are a few open questions left, namely the terminology
> > and design of ContextKey API. On the former topic, I'm quite
> > happy with the latest version: Execution Contex
On Fri, 18 Aug 2017 16:33:27 -0400
Yury Selivanov wrote:
>
> There are a few open questions left, namely the terminology
> and design of ContextKey API. On the former topic, I'm quite
> happy with the latest version: Execution Context, Logical
> Context, and Context Key.
I don't really like it.
On 19 August 2017 at 06:33, Yury Selivanov wrote:
> Hi,
>
> This is a third iteration of the PEP.
>
> There was some really good feedback on python-ideas and
> the discussion thread became hard to follow again, so I decided to
> update the PEP only three days after I published the previous
> versi
Hi,
This is a third iteration of the PEP.
There was some really good feedback on python-ideas and
the discussion thread became hard to follow again, so I decided to
update the PEP only three days after I published the previous
version.
Summary of the changes can be found in the "Version History"
60 matches
Mail list logo
