Hi Jim,
Sorry, I don't answer all questions/points directly. We are working
on a new version of the PEP that will hopefully address most of them.
Some comments inlined below:
On Thu, Aug 24, 2017 at 12:32 AM, Jim J. Jewett wrote:
[..]
> I still don't see how this is different from a ChainMap.
In https://mail.python.org/pipermail/python-dev/2017-August/148869.html
Nick Coghlan wrote:
> * 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
So when creating a generator, we w
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
13 matches
Mail list logo
