[Python-Dev] PEP 550 v4

[Nathaniel Smith]

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