Merge remote-tracking branch 'upstream/main' into release-toml

# Conflicts:
#	peps/pep-0719.rst

Author: AA-Turner

.github/CODEOWNERS

@@ -674,7 +674,8 @@ peps/pep-0792.rst  @dstufft
 peps/pep-0793.rst  @encukou
 peps/pep-0794.rst  @brettcannon
 peps/pep-0798.rst  @JelleZijlstra
-# ...
+peps/pep-0799.rst  @pablogsal
+peps/pep-0800.rst  @JelleZijlstra
 peps/pep-0801.rst  @warsaw
 # ...
 peps/pep-2026.rst  @hugovk

.github/workflows/test.yml

@@ -35,6 +35,7 @@ jobs:
         - "3.11"
         - "3.12"
         - "3.13"
+        - "3.14"
         os:
         - "windows-latest"
         - "macos-latest"

Makefile

@@ -64,6 +64,7 @@ venv:
 		echo "venv already exists."; \
 		echo "To recreate it, remove it first with \`make clean-venv'."; \
 	else \
+		set -e; \
 		echo "Creating venv in $(VENVDIR)"; \
 		if $(UV) --version >/dev/null 2>&1; then \
 			$(UV) venv --python=$(PYTHON) $(VENVDIR); \

peps/pep-0011.rst

@@ -102,7 +102,7 @@ Tier 2
 Target Triple                 Notes                      Contacts
 ============================= ========================== ========
 aarch64-unknown-linux-gnu     glibc, clang               Victor Stinner, Gregory P. Smith
-wasm32-unknown-wasip1         WASI SDK, Wasmtime         Brett Cannon, Eric Snow
+wasm32-unknown-wasip1         WASI SDK, Wasmtime         Brett Cannon, Michael Droettboom
 x86_64-unknown-linux-gnu      glibc, clang               Victor Stinner, Gregory P. Smith
 ============================= ========================== ========
 

peps/pep-0694.rst

@@ -50,10 +50,10 @@ Actual:
 - 3.14.0 beta 2: Monday, 2025-05-26
 - 3.14.0 beta 3: Tuesday, 2025-06-17
 - 3.14.0 beta 4: Tuesday, 2025-07-08
+- 3.14.0 candidate 1: Tuesday, 2025-07-22
 
 Expected:
 
-- 3.14.0 candidate 1: Tuesday, 2025-07-22
 - 3.14.0 candidate 2: Tuesday, 2025-08-26
 - 3.14.0 final: Tuesday, 2025-10-07
 

peps/pep-0745.rst

@@ -183,7 +183,7 @@ expression, and it represents the type described by that type expression.
 
 ``TypeForm`` is a special form that, when used in a type expression, describes
 a set of type form objects. It accepts a single type argument, which must be a
-valid type expression. ``TypeForm[T]`` describes the set of all type form
+:ref:`valid type expression <valid-type-expressions>`. ``TypeForm[T]`` describes the set of all type form
 objects that represent the type ``T`` or types that are
 :term:`assignable to <typing:assignable>` ``T``. For example,
 ``TypeForm[str | None]`` describes the set of all type form objects
@@ -218,9 +218,7 @@ equivalent to ``TypeForm[Any]``.
 Implicit ``TypeForm`` Evaluation
 --------------------------------
 
-When a static type checker encounters an expression that follows all of the
-syntactic, semantic and contextual rules for a type expression as detailed
-in the typing spec, the evaluated type of this expression should be assignable
+When a static type checker encounters a valid type expression, the evaluated type of this expression should be assignable
 to ``TypeForm[T]`` if the type it describes is assignable to ``T``.
 
 For example, if a static type checker encounters the expression ``str | None``,
@@ -248,6 +246,11 @@ be assignable to ``TypeForm``::
 
   v5: TypeForm[set[str]] = "set[str]"  # OK
 
+.. _valid-type-expressions:
+
+Valid Type Expressions
+----------------------
+
 The typing spec defines syntactic rules for type expressions in the form of a
 :ref:`formal grammar <typing:expression-grammar>`. Semantic rules are specified
 as comments along with the grammar definition. Contextual requirements are detailed
@@ -256,8 +259,11 @@ type expressions. For example, the special form ``Self`` can be used in a
 type expression only within a class, and a type variable can be used within
 a type expression only when it is associated with a valid scope.
 
-Expressions that violate one or more of the syntactic, semantic, or contextual
-rules for type expressions should not evaluate to a ``TypeForm`` type.::
+A valid type expression is an expression that follows all of the syntactic,
+semantic, and contextual rules for a type expression.
+
+Expressions that are not valid type expressions should not evaluate to a
+``TypeForm`` type::
 
   bad1: TypeForm = tuple()  # Error: Call expression not allowed in type expression
   bad2: TypeForm = (1, 2)  # Error: Tuple expression not allowed in type expression

peps/pep-0747.rst

@@ -209,7 +209,7 @@ Like ``Template``, it is a new class found in the :mod:`!string.templatelib` mod
         def __new__(
             cls,
             value: object,
-            expression: str,
+            expression: str = "",
             conversion: Literal["a", "r", "s"] | None = None,
             format_spec: str = "",
         ):
@@ -226,14 +226,20 @@ The ``value`` attribute is the evaluated result of the interpolation:
     template = t"Hello {name}"
     assert template.interpolations[0].value == "World"
 
-The ``expression`` attribute is the *original text* of the interpolation:
+When interpolations are created from a template string literal, the
+``expression`` attribute contains the *original text* of the interpolation:
 
 .. code-block:: python
 
     name = "World"
     template = t"Hello {name}"
     assert template.interpolations[0].expression == "name"
 
+When developers explicitly construct an ``Interpolation``, they may optionally
+provide a value for the ``expression`` attribute. Even though it is stored as
+a string, this *should* be a valid Python expression. If no value is provided,
+the ``expression`` attribute defaults to the empty string (``""``).
+
 We expect that the ``expression`` attribute will not be used in most template
 processing code. It is provided for completeness and for use in debugging and
 introspection. See both the `Common Patterns Seen in Processing Templates`_
@@ -462,7 +468,9 @@ The debug specifier, ``=``, is supported in template strings and behaves similar
 to how it behaves in f-strings, though due to limitations of the implementation
 there is a slight difference.
 
-In particular, ``t'{value=}'`` is treated as ``t'value={value!r}'``:
+In particular, ``t'{value=}'`` is treated as ``t'value={value!r}'``. The first
+static string is rewritten from ``""`` to ``"value="`` and the ``conversion``
+defaults to ``r``:
 
 .. code-block:: python
 
@@ -472,8 +480,11 @@ In particular, ``t'{value=}'`` is treated as ``t'value={value!r}'``:
     assert template.interpolations[0].value == "World"
     assert template.interpolations[0].conversion == "r"
 
-If a separate format string is also provided, ``t'{value=:fmt}`` is treated
-instead as ``t'value={value!s:fmt}'``.
+If a conversion is explicitly provided, it is kept: ``t'{value=!s}'``
+is treated as ``t'value={value!s}'``.
+
+If a format string is provided without a conversion, the ``conversion``
+is set to ``None``: ``t'{value=:fmt}'`` is treated as ``t'value={value:fmt}'``.
 
 Whitespace is preserved in the debug specifier, so ``t'{value = }'`` is
 treated as ``t'value = {value!r}'``.
@@ -549,7 +560,7 @@ Examples
 ========
 
 All examples in this section of the PEP have fully tested reference implementations
-available in the public `pep750-examples <https://github.com/davepeck/pep750-examples>`_
+available in the public `pep750-examples <https://github.com/t-strings/pep750-examples>`_
 git repository.
 
 
@@ -602,8 +613,8 @@ specifiers like ``:.2f``. The full code is fairly simple:
 
    See `fstring.py`__ and `test_fstring.py`__.
 
-   __ https://github.com/davepeck/pep750-examples/blob/main/pep/fstring.py
-   __ https://github.com/davepeck/pep750-examples/blob/main/pep/test_fstring.py
+   __ https://github.com/t-strings/pep750-examples/blob/main/pep/fstring.py
+   __ https://github.com/t-strings/pep750-examples/blob/main/pep/test_fstring.py
 
 
 Example: Structured Logging
@@ -775,8 +786,8 @@ logging:
 
    See `logging.py`__ and `test_logging.py`__.
 
-   __ https://github.com/davepeck/pep750-examples/blob/main/pep/logging.py
-   __ https://github.com/davepeck/pep750-examples/blob/main/pep/test_logging.py
+   __ https://github.com/t-strings/pep750-examples/blob/main/pep/logging.py
+   __ https://github.com/t-strings/pep750-examples/blob/main/pep/test_logging.py
 
 
 Example: HTML Templating
@@ -785,7 +796,7 @@ Example: HTML Templating
 This PEP contains several short HTML templating examples. It turns out that the
 "hypothetical" ``html()`` function mentioned in the  `Motivation`_ section
 (and a few other places in this PEP) exists and is available in the
-`pep750-examples repository <https://github.com/davepeck/pep750-examples/>`_.
+`pep750-examples repository <https://github.com/t-strings/pep750-examples/>`_.
 If you're thinking about parsing a complex grammar with template strings, we
 hope you'll find it useful.
 
@@ -1081,8 +1092,8 @@ and is able to ``await`` an interpolation's value.
 
    See `afstring.py`__ and `test_afstring.py`__.
 
-   __ https://github.com/davepeck/pep750-examples/blob/main/pep/afstring.py
-   __ https://github.com/davepeck/pep750-examples/blob/main/pep/test_afstring.py
+   __ https://github.com/t-strings/pep750-examples/blob/main/pep/afstring.py
+   __ https://github.com/t-strings/pep750-examples/blob/main/pep/test_afstring.py
 
 
 Approaches to Template Reuse
@@ -1157,16 +1168,16 @@ which supports the full grammar of format strings.
 
    See `format.py`__ and `test_format.py`__.
 
-   __ https://github.com/davepeck/pep750-examples/blob/main/pep/format.py
-   __ https://github.com/davepeck/pep750-examples/blob/main/pep/test_format.py
+   __ https://github.com/t-strings/pep750-examples/blob/main/pep/format.py
+   __ https://github.com/t-strings/pep750-examples/blob/main/pep/test_format.py
 
 
 Reference Implementation
 ========================
 
 A CPython implementation of PEP 750 is `available <https://github.com/lysnikolaou/cpython/tree/tstrings>`_.
 
-There is also a public repository of `examples and tests <https://github.com/davepeck/pep750-examples>`_
+There is also a public repository of `examples and tests <https://github.com/t-strings/pep750-examples>`_
 built around the reference implementation. If you're interested in playing with
 template strings, this repository is a great place to start.