[Python-Dev] PEP 550 v3 naming

Yury Selivanov yselivanov.ml at gmail.com
Wed Aug 23 14:27:55 EDT 2017


On Wed, Aug 23, 2017 at 12:56 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 23 Aug 2017 12:19:40 -0400
> Yury Selivanov <yselivanov.ml at gmail.com> 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 from outside code, which is
> not the case for a generator (where resumption is controlled by
> explicit next() calls or iteration by the consumer).

I agree. That's why we are rewriting the PEP without mentioning
"logical threads".

>
> That is also why I proposed the more general "task" (and "task
> context").  Of course, capitalized "Task" is given a specific
> meaning by asyncio...

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. DynamicContext: close to "dynamic scoping", but tries to avoid
mentioning "scopes". There are only a few languages where dynamic
scoping is implemented, so people are generally not aware of it.

2. ContextFrame and all frame-related names: implies that EC is
somehow implemented on top of frames or is frame-specific (which is
not always true).

3. ImplicitContext: covers one specific property observed from
specific examples.  Context in PEP 550 is managed explicitly in some
cases. There are many use cases when API users will be working with it
explicitly too (to wrirte/read data from it). FWIW I believe that
"ExplicitContext" would be more accurate than "ImplicitContext".

4. LocalContext: we use "local" to describe local variables and
scoping in Python, we want to avoid any confusion here.

5. TaskContext: works for asynchronous tasks, but not for generators.

I don't think that replacing LogicalContext with any name in this list
will make any improvement.

Yury


More information about the Python-Dev mailing list