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
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
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
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
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
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
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.
>
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
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
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
>
Hi Nick,
On 23.08.17 07:41, Nick Coghlan wrote:
> On 23 August 2017 at 00:09, stackless wrote:
>> Hi again,
>>
>> I am trying to support the limited Api (PEP 384) for PySide. Fortunately,
>> everything worked out of the box, just the datetime module gives me
>> a problem.
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
15 matches
Mail list logo