This behavior is rather surprising and it was not clearly specified.
(cherry picked from commit 9e0b11eb21)
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Define 'nonlocal scopes' in a way that excludes class scopes.
Rearrange the rest of the doc. Add "Programmer's note".
(cherry picked from commit 025ef7a5f7)
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
gh-101100: Fix Sphinx nitpicks in `library/inspect.rst` and `reference/simple_stmts.rst` (GH-113107)
(cherry picked from commit 4b3cb082da)
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Replace the esoteric term 'datum' when describing dict comprehensions (GH-106119)
(cherry picked from commit 987b712b4a)
Co-authored-by: Ned Batchelder <ned@nedbatchelder.com>
* Uncomment builtin removal in pairindextypes
* Use new-style index directive ('builtin') - C API
* Use new-style index directive ('builtin') - Extending
* Use new-style index directive ('builtin') - Library
* Use new-style index directive ('builtin') - Reference
* Use new-style index directive ('builtin') - Tutorial
* 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
Update documentation section for "Future statements" to reflect that `from __future__ import annotations` is on by default, and no features require using the future statement now.
Use an unique identifier for the different grammars documented using
the Sphinx productionlist markup.
productionlist markups of the same grammar, like "expressions" or
"compound statements", use the same identifier "python-grammar".
Prefer the full wording instead, as it is more meaningful for someone not familiar with the terms.
Also, LFS/RHS is not used anywhere else in the documentation, while left/right-hand side mentions are common.
The documentation was not covering multiple targets enclosed by
parenthesis nor multiple targets enclosed by brackets, adding them all
would be heavy, an else cover them all and is lighter to read.
* Document `from __future__ import annotations`
* Provide plumbing and tests for `from __future__ import annotations`
* Implement unparsing the AST back to string form
This is required for PEP 563 and as such only implements a part of the
unparsing process that covers expressions.