Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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) >

Re: [Python-Dev] PEP 550 v3 naming

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.

Re: [Python-Dev] PEP 550 v3 naming

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 =

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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)

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

> 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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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. >

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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.

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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 >

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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.

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

-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

Re: [Python-Dev] PEP 550 v3 naming

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

Re: [Python-Dev] PEP 550 v3 naming

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).