[Python-Dev] PEP 550 v4 (original) (raw)

Nathaniel Smith njs at pobox.com
Wed Sep 6 05:13:54 EDT 2017

On Wed, Sep 6, 2017 at 1:49 AM, Ivan Levkivskyi <levkivskyi at gmail.com> wrote:

Another comment from bystander point of view: it looks like the discussions of API design and implementation are a bit entangled here. This is much better in the current version of the PEP, but still there is a feelling that some design decisions are influenced by the implementation strategy.

As I currently see the "philosophy" at large is like this: there are different level of coupling between concurrently executing code: * processes: practically not coupled, designed to be long running * threads: more tightly coupled, designed to be less long-lived, context is managed by threading.local, which is not inherited on "forking" * tasks: tightly coupled, designed to be short-lived, context will be managed by PEP 550, context is inherited on "forking" This seems right to me. Normal generators fall out from this "scheme", and it looks like their behavior is determined by the fact that coroutines are implemented as generators. What I think miht help is to add few more motivational examples to the design section of the PEP.

Literally the first motivating example at the beginning of the PEP ('def fractions ...') involves only generators, not coroutines, and only works correctly if generators get special handling. (In fact, I'd be curious to see how Greg's {push,pop}local_storage could handle this case.) The implementation strategy changed radically between v1 and v2 because of considerations around generator (not coroutine) semantics. I'm not sure what more it can do to dispel these feelings :-)._

-n

-- Nathaniel J. Smith -- https://vorpus.org

More information about the Python-Dev mailing list