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
_______________________________________________
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
