[Python-Dev] PEP 550 v3 naming (original) (raw)

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