Merge branch 'main' into ww/tp-discovery-pep

Author: woodruffw

.github/CODEOWNERS

@@ -679,6 +679,7 @@ peps/pep-0800.rst  @JelleZijlstra
 peps/pep-0801.rst  @warsaw
 peps/pep-0802.rst  @AA-Turner
 peps/pep-0803.rst  @encukou
+peps/pep-0804.rst  @pradyunsg
 peps/pep-0807.rst  @dstufft
 # ...
 peps/pep-2026.rst  @hugovk

peps/pep-0351.rst

@@ -38,8 +38,8 @@ It is conceivable that third party objects also have similar mutable
 and immutable counterparts, and it would be useful to have a standard
 protocol for conversion of such objects.
 
-sets.Set objects expose a "protocol for automatic conversion to
-immutable" so that you can create sets.Sets of sets.Sets.  :pep:`218`
+``sets.Set`` objects expose a "protocol for automatic conversion to
+immutable" so that you can create ``sets.Set``'s of ``sets.Set``'s.  :pep:`218`
 deliberately dropped this feature from built-in sets.  This PEP
 advances that the feature is still useful and proposes a standard
 mechanism for its support.
@@ -48,22 +48,24 @@ mechanism for its support.
 Proposal
 ========
 
-It is proposed that a new built-in function called freeze() is added.
+It is proposed that a new built-in function called ``freeze()`` is added.
 
-If freeze() is passed an immutable object, as determined by hash() on
-that object not raising a TypeError, then the object is returned
+If ``freeze()`` is passed an immutable object, as determined by ``hash()`` on
+that object not raising a ``TypeError``, then the object is returned
 directly.
 
-If freeze() is passed a mutable object (i.e. hash() of that object
-raises a TypeError), then freeze() will call that object's
-__freeze__() method to get an immutable copy.  If the object does not
-have a __freeze__() method, then a TypeError is raised.
+If ``freeze()`` is passed a mutable object (i.e. ``hash()`` of that object
+raises a ``TypeError``), then ``freeze()`` will call that object's
+``__freeze__()`` method to get an immutable copy.  If the object does not
+have a ``__freeze__()`` method, then a ``TypeError`` is raised.
 
 
 Sample implementations
 ======================
 
-Here is a Python implementation of the freeze() built-in::
+Here is a Python implementation of the ``freeze()`` built-in:
+
+.. code-block:: python
 
     def freeze(obj):
         try:
@@ -73,9 +75,11 @@ Here is a Python implementation of the freeze() built-in::
             freezer = getattr(obj, '__freeze__', None)
             if freezer:
                 return freezer()
-            raise TypeError('object is not freezable')``
+            raise TypeError('object is not freezable')
+
+Here are some code samples which show the intended semantics:
 
-Here are some code samples which show the intended semantics::
+.. code-block:: python
 
     class xset(set):
         def __freeze__(self):
@@ -104,6 +108,8 @@ Here are some code samples which show the intended semantics::
         def __freeze__(self):
             return imdict(self)
 
+.. code-block:: python-console
+
     >>> s = set([1, 2, 3])
     >>> {s: 4}
     Traceback (most recent call last):
@@ -140,9 +146,9 @@ Reference implementation
 ========================
 
 Patch 1335812_ provides the C implementation of this feature.  It adds the
-freeze() built-in, along with implementations of the __freeze__()
+``freeze()`` built-in, along with implementations of the ``__freeze__()``
 method for lists and sets.  Dictionaries are not easily freezable in
-current Python, so an implementation of dict.__freeze__() is not
+current Python, so an implementation of ``dict.__freeze__()`` is not
 provided yet.
 
 .. _1335812: http://sourceforge.net/tracker/index.php?func=detail&aid=1335812&group_id=5470&atid=305470
@@ -155,11 +161,11 @@ Open issues
 - Should dicts and sets automatically freeze their mutable keys?
 
 - Should we support "temporary freezing" (perhaps with a method called
-  __congeal__()) a la __as_temporarily_immutable__() in sets.Set?
+  ``__congeal__()``) a la ``__as_temporarily_immutable__()`` in ``sets.Set``?
 
-- For backward compatibility with sets.Set, should we support
-  __as_immutable__()?  Or should __freeze__() just be renamed to
-  __as_immutable__()?
+- For backward compatibility with ``sets.Set``, should we support
+  ``__as_immutable__()``?  Or should ``__freeze__()`` just be renamed to
+  ``__as_immutable__()``?
 
 
 Copyright

peps/pep-0518.rst

@@ -164,9 +164,9 @@ the ``pyproject.toml`` file will be::
 
   [build-system]
   # Minimum requirements for the build system to execute.
-  requires = ["setuptools", "wheel"]  # PEP 508 specifications.
+  requires = ["setuptools"]  # PEP 508 specifications.
 
-Because the use of setuptools and wheel are so expansive in the
+Because the use of setuptools is so expansive in the
 community at the moment, build tools are expected to use the example
 configuration file above as their default semantics when a
 ``pyproject.toml`` file is not present.

peps/pep-0679.rst

@@ -7,7 +7,8 @@ Status: Draft
 Type: Standards Track
 Created: 07-Jan-2022
 Python-Version: 3.15
-Post-History: `10-Jan-2022 <https://discuss.python.org/t/pep-679-allow-parentheses-in-assert-statements/13003>`__
+Post-History: `08-Sep-2025 <https://discuss.python.org/t/pep-679-new-assert-statement-syntax-with-parentheses/103634>`__,
+              `10-Jan-2022 <https://discuss.python.org/t/pep-679-allow-parentheses-in-assert-statements/13003>`__
 
 
 Abstract
@@ -132,10 +133,10 @@ specification.
 (Note that, without the warning specification the pure parser implementation is
 a small grammar change [#previmp]_).
 To raise the warning, the compiler must
-be aware of the new syntax, which means that a flag would be necessary as
-otherwise the information is lost during parsing.
-As such, the AST of an :keyword:`assert` would look like so,
-with a ``paren_syntax`` flag::
+be aware of the new syntax, this means that an optional flag would be necessary
+as otherwise the information is lost during parsing.
+As such, the AST of an :keyword:`assert` with parentheses would look like so,
+with a ``paren_syntax=1`` flag::
 
     >>> print(ast.dump(ast.parse('assert(True, "Error message")'), indent=4))
     Module(
@@ -145,8 +146,6 @@ with a ``paren_syntax`` flag::
                 msg=Constant(value='Error message'),
                 paren_syntax=1)])
 
-The flag would be removed in 3.18 along with the :exc:`SyntaxWarning`.
-
 
 Implementing in the compiler
 ----------------------------