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. -- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170906/91717d6d/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4