-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-10544: Deprecate "yield" in comprehensions and generator expressions. #4579
bpo-10544: Deprecate "yield" in comprehensions and generator expressions. #4579
Conversation
@serhiy-storchaka Do you mind if I just edit some of the docs wording directly? I think that will be easier than trying to describe the edits I would recommend. |
I will be grateful if you do this. |
- updated the comprehension scoping definition to use some of the words from the generator expression definition - added appropriate versionadded/changed directives -
Doc/reference/expressions.rst
Outdated
@@ -201,6 +210,12 @@ or :keyword:`await` expressions it is called an | |||
suspend the execution of the coroutine function in which it appears. | |||
See also :pep:`530`. | |||
|
|||
.. versionadded:: 3.6 | |||
Asynchronous comprehensions were introduced |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missed a period.
Doc/reference/expressions.rst
Outdated
and then passed as an argument to the implictly nested scope. Subsequent | ||
:keyword:`for` clauses cannot be evaluated in the enclosing scope since they | ||
may depend on the previous :keyword:`for` loop. For example: | ||
``[x*y for x in range(10) for y in bar(x)]``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe use more concrete real-world example? E.g. for y in range(x+1, 10)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I lifted this one directly from the generator expression docs, but changing it in both places would definitely be reasonable.
Doc/reference/expressions.rst
Outdated
.. versionadded:: 3.6 | ||
Asynchronous comprehensions were introduced | ||
|
||
.. versionchanged:: 3.7 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't be deprecated
or deprecated-removed
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aye, it should - I just forgot there was a specific directive for deprecations. I'll go through and fix all the cases.
OK, I've made my documentation edits. @gvanrossum I think it would be helpful if you could review the proposed language reference updates directly, or else nominate someone else to do so. |
Doc/whatsnew/3.7.rst
Outdated
@@ -563,7 +563,10 @@ Deprecated | |||
potentially returning a :term:`generator-iterator` object), while generator | |||
expressions won't attempt to interleave their implicit output with the output | |||
from any explicit yield expressions. | |||
(Contributed by Serhiy Storchaka in :issue:`10544`.) | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trailing spaces.
Doc/reference/expressions.rst
Outdated
|
||
.. versionchanged:: 3.7 | ||
.. deprecated:: 3.7 | ||
``yield`` and ``yield from`` deprecated in the implicitly nested scope |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missed a period.
Doc/whatsnew/3.7.rst
Outdated
in comprehensions and generator expressions (aside from the outermost iterable | ||
defined in the leftmost :keyword`for` clause). This ensures that comprehensions | ||
always immediately return a container of the appropriate type (rather than | ||
potentially returning a :term:`generator-iterator` object), while generator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Warning, treated as error:
/home/travis/build/python/cpython/Doc/whatsnew/3.7.rst:559:term not in glossary: generator-iterator
Doc/reference/expressions.rst
Outdated
Asynchronous comprehensions were introduced. | ||
|
||
.. deprecated:: 3.7 | ||
``yield`` and ``yield from`` deprecated in the implicitly nested scope |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missed a period.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are some suggestions to tighten the docs. Thanks to both of you for taking care of this!
Doc/reference/expressions.rst
Outdated
@@ -183,8 +183,20 @@ by considering each of the :keyword:`for` or :keyword:`if` clauses a block, | |||
nesting from left to right, and evaluating the expression to produce an element | |||
each time the innermost block is reached. | |||
|
|||
Note that the comprehension is executed in a separate scope, so names assigned | |||
to in the target list don't "leak" into the enclosing scope. | |||
However, aside from the leftmost :keyword:`for` clause, the comprehension is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "leftmost for
clause" is still ambiguous. Does this include the in for a[<expr>] in ...
? It should not, but I would assume it's part of "the for
clause." Maybe say "the iterable in the leftmost for
clause"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using just "iterable" ended up looking odd in context (since executing an iterable could be taken to mean iterating over it).
However, "the iterable expression in the leftmost :keyword:for
clause" reads reasonably well to me, and I also made it explicit that the leftmost filter condition is evaluated in the nested scope.
It may be worth our while to explicitly define "outermost iterable" as a formal term in the glossary, but I think that would be better handled as a distinct docs RFE.
Doc/whatsnew/3.7.rst
Outdated
@@ -556,6 +556,18 @@ Other CPython Implementation Changes | |||
Deprecated | |||
========== | |||
|
|||
* Yield expressions (both ``yield`` and ``yield from`` clauses) are now deprecated | |||
in comprehensions and generator expressions (aside from the outermost iterable | |||
defined in the leftmost :keyword:`for` clause). This ensures that comprehensions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd drop "defined" here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the changes I made to the language reference, I replaced "the outermost iterable defined in" with "the iterable expression in" here.
- consistently use "leftmost" (never "outermost") - explicitly exclude the filter condition from eager evaluation - better align wording for comprehensions and generator expressions
Docs LGTM now. |
to get a more accurate error report */ | ||
PyErr_Clear(); | ||
PyErr_SetObject(PyExc_SyntaxError, msg); | ||
PyErr_SyntaxLocationObject(st->st_filename, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Ping. |
Thank you for your documentation changes @ncoghlan! |
…ons in Py3k mode. (pythonGH-4579)
https://bugs.python.org/issue10544