gh-135110: Fix misleading `generator.close()` documentation (GH-135152)
The documentation incorrectly stated that generator.close() 'raises' a
GeneratorExit exception. This was misleading because the method doesn't
raise the exception to the caller - it sends the exception internally
to the generator and returns None.
(cherry picked from commit 0d76dccc3b)
Co-authored-by: Connor Denihan <188690869+cdenihan@users.noreply.github.com>
Docs: Add cross-reference for `positional_item` in the `calls` productionlist (GH-129977)
Add missing hyperlink for `positional_item`
(cherry picked from commit d2154912b3)
Co-authored-by: HarryLHW <123lhw321@gmail.com>
gh-135171: Update documentation for the generator expression (GH-135351)
* gh-135171: Update documentation for the generator expression
Document that the iterator for the leftmost "for" clause is created
immediately.
* Update Doc/reference/expressions.rst
---------
(cherry picked from commit 8979d3afe3)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Brian Skinn <brian.skinn@gmail.com>
Document that return-less user-defined functions return None (GH-126769)
(cherry picked from commit e0692f1165)
Co-authored-by: John Marshall <jmarshall@hey.com>
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
gh-81263: Add assignment expressions to `help` (#124641)
* Add assignment expression (:=) to `help`
* Update index for Assignment Expressions to include pair of `assignment; expression`
gh-115528: Update language reference for PEP 646 (GH-121181)
To recap: the objective is to make starred expressions valid in `subscription`,
which is used for generics: `Generic[...]`, `list[...]`, etc.
What _is_ gramatically valid in such contexts? Seemingly any of the following.
(At least, none of the following throw `SyntaxError` in a 3.12.3 REPL.)
Generic[x]
Generic[*x]
Generic[*x, y]
Generic[y, *x]
Generic[x := 1]
Generic[x := 1, y := 2]
So introducting
flexible_expression: expression | assignment_expression | starred_item
end then switching `subscription` to use `flexible_expression` sorts that.
But then we need to field `yield` - for which any of the following are
apparently valid:
yield x
yield x,
yield x, y
yield *x,
yield *x, *y
Introducing a separate `yield_list` is the simplest way I've been figure out to
do this - separating out the special case of `starred_item ,`.
(cherry picked from commit 7d3497f617)
Co-authored-by: Matthew Rahtz <matthew.rahtz@gmail.com>
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
gh-114104: clarify asynchronous comprehension docs to match runtime behavior (GH-121175)
(cherry picked from commit 91313afdb3)
Co-authored-by: Danny Yang <yangdanny97@users.noreply.github.com>
doc: Mention the missing reflected special methods for all binary operations (GH-119931)
(cherry picked from commit bf5e1065f4)
Co-authored-by: Paulo Freitas <me@paulofreitas.me>
gh-111944: Clarify where assignment expressions require ()s
Augment the list of places where parentheses are
required around assignnment statements. In particular,
'a := 0' and 'a = b := 1' are syntax errors.
* Uncomment object removal in pairindextypes
* Use new-style index directive ('object') - C API
* Use new-style index directive ('object') - Library
* Use new-style index directive ('object') - Reference
* Use new-style index directive ('object') - Tutorial
* Add walrus operator to the index
* Add named expression to the index
Co-authored-by: Mariatta Wijaya <Mariatta@users.noreply.github.com>
* Fix indentation and add missing newline
Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>
Co-authored-by: Mariatta Wijaya <Mariatta@users.noreply.github.com>
Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>
Keep track of whether unsafe_tuple_compare() calls are resolved by the very
first tuple elements, and adjust strategy accordingly. This can significantly
cut the number of calls made to the full-blown PyObject_RichCompareBool(),
and especially when duplicates are rare.
Co-authored-by: Łukasz Langa <lukasz@langa.pl>