Hi Stephen, Thanks a lot for the feedback and suggestions. I'll apply them to the PEP. On 2015-04-28 11:03 PM, Stephen J. Turnbull wrote: > Literary critic here. > > In section "Specification" > > > It is strongly suggested that the reader understands how coroutines > > are implemented in Python (PEP 342 and PEP 380). It is also > > recommended to read PEP 3156 (asyncio framework) and PEP 3152 > > (Cofunctions). > > The usual phrasing of "strongly suggested" in specifications is > "presumes knowledge". Some people think "strongly suggest <do>ing" is > presumptuous and condescending, YMMV. Also, the relationship to PEP > 3152 should be mentioned IMO. I propose: > > This specification presumes knowledge of the implementation of > coroutines in Python (PEP 342 and PEP 380). Motivation for the > syntax changes proposed here comes from the asyncio framework (PEP > 3156) and the "Cofunctions" proposal (PEP 3152, now rejected in > favor of this specification). Your wording is 100% better and it's time to mention PEP 3152 too. > > I'm not entirely happy with my phrasing, because there are at least > four more or less different concepts that might claim the bare word > "coroutine": > > - this specification > - the implementation of this specification > - the syntax used to define coroutines via PEPs 342 and 380 > - the semantics of PEP 342/380 coroutines > > In both your original and my rephrasing, the use of "coroutine" > violates your convention that it refers to the PEP's proposed syntax > for coroutines. Instead it refers to the semantics of coroutines > implemented via PEP 342/380. This is probably the same concern that > motivated Guido's suggestion to use "native coroutines" for the PEP > 492 syntax (but I'm not Dutch, so maybe they're not the same :-). > > I feel this is a real hindrance to understanding for someone coming to > the PEP for the first time. You know which meaning of coroutine you > mean, but the new reader needs to think hard enough to disambiguate > every time the word occurs. If people agree with me, I could go > through the PEP and revise mentions of "coroutine" in "disambiguated" > style. I also like Guido's suggestion to use "native coroutine" term. I'll update the PEP (I have several branches of it in the repo that I need to merge before the rename). > > In section "Comprehensions": > > > For the sake of restricting the broadness of this PEP there is no > > new syntax for asynchronous comprehensions. This should be > > considered in a separate PEP, if there is a strong demand for this > > feature. > > Don't invite trouble.<wink /> How about: > > Syntax for asynchronous comprehensions could be provided, but this > construct is outside of the scope of this PEP. > > In section "Async lambdas" > > > Lambda coroutines are not part of this proposal. In this proposal they > > would look like ``async lambda(parameters): expression``. Unless there > > is a strong demand to have them as part of this proposal, it is > > recommended to consider them later in a separate PEP. > > Same recommendation as for "Comprehensions". I wouldn't mention the > tentative syntax, it is both obvious and inviting to trouble. Agree. Do you think it'd be better to combine comprehensions and async lambdas in one section? > > > > Acknowledgments > > =============== > > > > I thank Guido van Rossum, Victor Stinner, Elvis Pranskevichus, Andrew > > Svetlov, and Łukasz Langa for their initial feedback. > > A partial list of commentators I've found to be notable, YMMV: Sure! I was going to add everybody after the PEP is accepted/rejected/postponed. > > Greg Ewing for PEP 3152 and his Loyal Opposition to this PEP. > Mark Shannon's comments have led to substantial clarifications of > motivation for syntax, at least in my mind. > Paul Sokolovsky for information about the MicroPython implementation. > Thanks! Yury
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