<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Wed, Sep 6, 2017 at 12:13 PM, Nathaniel Smith </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 6, 2017 at 1:49 AM, Ivan Levkivskyi <<a href="mailto:levkivskyi@gmail.com">levkivskyi@gmail.com</a>> wrote:<br>
> Another comment from bystander point of view: it looks like the discussions<br>
> of API design and implementation are a bit entangled here.<br>
> This is much better in the current version of the PEP, but still there is a<br>
> _feelling_ that some design decisions are influenced by the implementation<br>
> strategy.<br>
><br>
> As I currently see the "philosophy" at large is like this:<br>
> there are different level of coupling between concurrently executing code:<br>
> * processes: practically not coupled, designed to be long running<br>
> * threads: more tightly coupled, designed to be less long-lived, context is<br>
> managed by threading.local, which is not inherited on "forking"<br>
> * tasks: tightly coupled, designed to be short-lived, context will be<br>
> managed by PEP 550, context is inherited on "forking"<br>
><br>
> This seems right to me.<br>
><br>
> Normal generators fall out from this "scheme", and it looks like their<br>
> behavior is determined by the fact that coroutines are implemented as<br>
> generators. What I think miht help is to add few more motivational examples<br>
> to the design section of the PEP.<br>
<br>
</span>Literally the first motivating example at the beginning of the PEP<br>
('def fractions ...') involves only generators, not coroutines, and<br>
only works correctly if generators get special handling. (In fact, I'd<br>
be curious to see how Greg's {push,pop}_local_storage could handle<br>
this case.) The implementation strategy changed radically between v1<br>
and v2 because of considerations around generator (not coroutine)<br>
semantics. I'm not sure what more it can do to dispel these feelings<br>
:-).<br><div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace,monospace">​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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">––Koos</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>