On Wed, Sep 6, 2017 at 12:13 PM, Nathaniel Smith <n...@pobox.com> wrote:
> On Wed, Sep 6, 2017 at 1:49 AM, Ivan Levkivskyi <levkivs...@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
> :-).
>
>
Just to mention that this is now closely related to the discussion on my
proposal on python-ideas. BTW, that proposal is now submitted as PEP 555 on
the peps repo.
––Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
_______________________________________________
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
