Merge branch 'main' into eager-tasks-factory

willingc · web-flow · commit 57b197f549fb · 2023-04-28T14:43:15.000-07:00
diff --git a/Doc/library/dataclasses.rst b/Doc/library/dataclasses.rst
@@ -437,19 +437,19 @@ Module contents
 
    The newly returned object is created by calling the :meth:`~object.__init__`
    method of the dataclass.  This ensures that
-   :ref:`__post_init__ <post-init-processing>`, if present, is also called.
+   :meth:`__post_init__`, if present, is also called.
 
    Init-only variables without default values, if any exist, must be
    specified on the call to :func:`replace` so that they can be passed to
-   :meth:`~object.__init__` and :ref:`__post_init__ <post-init-processing>`.
+   :meth:`~object.__init__` and :meth:`__post_init__`.
 
    It is an error for ``changes`` to contain any fields that are
    defined as having ``init=False``.  A :exc:`ValueError` will be raised
    in this case.
 
    Be forewarned about how ``init=False`` fields work during a call to
    :func:`replace`.  They are not copied from the source object, but
-   rather are initialized in :ref:`__post_init__ <post-init-processing>`, if they're
+   rather are initialized in :meth:`__post_init__`, if they're
    initialized at all.  It is expected that ``init=False`` fields will
    be rarely and judiciously used.  If they are used, it might be wise
    to have alternate class constructors, or perhaps a custom
@@ -510,30 +510,31 @@ Module contents
 Post-init processing
 --------------------
 
-The generated :meth:`~object.__init__` code will call a method named
-:meth:`!__post_init__`, if :meth:`!__post_init__` is defined on the
-class.  It will normally be called as ``self.__post_init__()``.
-However, if any ``InitVar`` fields are defined, they will also be
-passed to :meth:`!__post_init__` in the order they were defined in the
-class.  If no :meth:`~object.__init__` method is generated, then
-:meth:`!__post_init__` will not automatically be called.
+.. function:: __post_init__()
 
-Among other uses, this allows for initializing field values that
-depend on one or more other fields.  For example::
+   When defined on the class, it will be called by the generated
+   :meth:`~object.__init__`, normally as ``self.__post_init__()``.
+   However, if any ``InitVar`` fields are defined, they will also be
+   passed to :meth:`__post_init__` in the order they were defined in the
+   class.  If no :meth:`~object.__init__` method is generated, then
+   :meth:`__post_init__` will not automatically be called.
 
-    @dataclass
-    class C:
-        a: float
-        b: float
-        c: float = field(init=False)
+   Among other uses, this allows for initializing field values that
+   depend on one or more other fields.  For example::
 
-        def __post_init__(self):
-            self.c = self.a + self.b
+     @dataclass
+     class C:
+         a: float
+         b: float
+         c: float = field(init=False)
+
+         def __post_init__(self):
+             self.c = self.a + self.b
 
 The :meth:`~object.__init__` method generated by :func:`dataclass` does not call base
 class :meth:`~object.__init__` methods. If the base class has an :meth:`~object.__init__` method
 that has to be called, it is common to call this method in a
-:meth:`!__post_init__` method::
+:meth:`__post_init__` method::
 
     @dataclass
     class Rectangle:
@@ -552,7 +553,7 @@ don't need to be called, since the derived dataclass will take care of
 initializing all fields of any base class that is a dataclass itself.
 
 See the section below on init-only variables for ways to pass
-parameters to :meth:`!__post_init__`.  Also see the warning about how
+parameters to :meth:`__post_init__`.  Also see the warning about how
 :func:`replace` handles ``init=False`` fields.
 
 Class variables
@@ -576,7 +577,7 @@ is an ``InitVar``, it is considered a pseudo-field called an init-only
 field.  As it is not a true field, it is not returned by the
 module-level :func:`fields` function.  Init-only fields are added as
 parameters to the generated :meth:`~object.__init__` method, and are passed to
-the optional :ref:`__post_init__ <post-init-processing>` method.  They are not otherwise used
+the optional :meth:`__post_init__` method.  They are not otherwise used
 by dataclasses.
 
 For example, suppose a field will be initialized from a database, if a
diff --git a/Doc/library/itertools.rst b/Doc/library/itertools.rst
@@ -789,6 +789,7 @@ which incur interpreter overhead.
 .. testcode::
 
    import collections
+   import functools
    import math
    import operator
    import random
@@ -1082,7 +1083,7 @@ The following recipes have a more mathematical flavor:
        # convolve(data, [1, -2, 1]) --> 2nd finite difference (2nd derivative)
        kernel = tuple(kernel)[::-1]
        n = len(kernel)
-       padded_signal = chain(repeat(0, n-1), signal, [0] * (n-1))
+       padded_signal = chain(repeat(0, n-1), signal, repeat(0, n-1))
        for window in sliding_window(padded_signal, n):
            yield math.sumprod(kernel, window)
 
@@ -1092,10 +1093,8 @@ The following recipes have a more mathematical flavor:
           (x - 5) (x + 4) (x - 3)  expands to:   x³ -4x² -17x + 60
        """
        # polynomial_from_roots([5, -4, 3]) --> [1, -4, -17, 60]
-       expansion = [1]
-       for r in roots:
-           expansion = convolve(expansion, (1, -r))
-       return list(expansion)
+       factors = zip(repeat(1), map(operator.neg, roots))
+       return list(functools.reduce(convolve, factors, [1]))
 
    def polynomial_eval(coefficients, x):
        """Evaluate a polynomial at a specific value.
diff --git a/Include/internal/pycore_code.h b/Include/internal/pycore_code.h
@@ -226,7 +226,7 @@ extern int _PyLineTable_PreviousAddressRange(PyCodeAddressRange *range);
 
 /* Specialization functions */
 
-extern void _Py_Specialize_LoadSuperAttr(PyObject *global_super, PyObject *class, PyObject *self,
+extern void _Py_Specialize_LoadSuperAttr(PyObject *global_super, PyObject *cls, PyObject *self,
                                          _Py_CODEUNIT *instr, PyObject *name, int load_method);
 extern void _Py_Specialize_LoadAttr(PyObject *owner, _Py_CODEUNIT *instr,
                                     PyObject *name);
diff --git a/Lib/test/test_patma.py b/Lib/test/test_patma.py
@@ -3165,6 +3165,19 @@ def f(command):             # 0
         self.assertListEqual(self._trace(f, "go x"), [1, 2, 3])
         self.assertListEqual(self._trace(f, "spam"), [1, 2, 3])
 
+    def test_unreachable_code(self):
+        def f(command):               # 0
+            match command:            # 1
+                case 1:               # 2
+                    if False:         # 3
+                        return 1      # 4
+                case _:               # 5
+                    if False:         # 6
+                        return 0      # 7
+
+        self.assertListEqual(self._trace(f, 1), [1, 2, 3])
+        self.assertListEqual(self._trace(f, 0), [1, 2, 5, 6])
+
     def test_parser_deeply_nested_patterns(self):
         # Deeply nested patterns can cause exponential backtracking when parsing.
         # See gh-93671 for more information.
diff --git a/Modules/_datetimemodule.c b/Modules/_datetimemodule.c
@@ -5144,13 +5144,13 @@ datetime_datetime_now_impl(PyTypeObject *type, PyObject *tz)
 static PyObject *
 datetime_utcnow(PyObject *cls, PyObject *dummy)
 {
-    PyErr_WarnEx(
-        PyExc_DeprecationWarning,
-        "datetime.utcnow() is deprecated and scheduled for removal in a future "
-        "version. Use timezone-aware objects to represent datetimes in UTC: "
-        "datetime.now(datetime.UTC).",
-        2
-    );
+    if (PyErr_WarnEx(PyExc_DeprecationWarning,
+        "datetime.utcnow() is deprecated and scheduled for removal in a "
+        "future version. Use timezone-aware objects to represent datetimes "
+        "in UTC: datetime.now(datetime.UTC).", 2))
+    {
+        return NULL;
+    }
     return datetime_best_possible(cls, _PyTime_gmtime, Py_None);
 }
 
@@ -5187,13 +5187,13 @@ datetime_fromtimestamp(PyObject *cls, PyObject *args, PyObject *kw)
 static PyObject *
 datetime_utcfromtimestamp(PyObject *cls, PyObject *args)
 {
-    PyErr_WarnEx(
-        PyExc_DeprecationWarning,
+    if (PyErr_WarnEx(PyExc_DeprecationWarning,
         "datetime.utcfromtimestamp() is deprecated and scheduled for removal "
         "in a future version. Use timezone-aware objects to represent "
-        "datetimes in UTC: datetime.now(datetime.UTC).",
-        2
-    );
+        "datetimes in UTC: datetime.now(datetime.UTC).", 2))
+    {
+        return NULL;
+    }
     PyObject *timestamp;
     PyObject *result = NULL;
 
diff --git a/Python/specialize.c b/Python/specialize.c
@@ -515,7 +515,7 @@ specialize_module_load_attr(
 /* Attribute specialization */
 
 void
-_Py_Specialize_LoadSuperAttr(PyObject *global_super, PyObject *class, PyObject *self,
+_Py_Specialize_LoadSuperAttr(PyObject *global_super, PyObject *cls, PyObject *self,
                              _Py_CODEUNIT *instr, PyObject *name, int load_method) {
     assert(ENABLE_SPECIALIZATION);
     assert(_PyOpcode_Caches[LOAD_SUPER_ATTR] == INLINE_CACHE_ENTRIES_LOAD_SUPER_ATTR);
@@ -528,11 +528,11 @@ _Py_Specialize_LoadSuperAttr(PyObject *global_super, PyObject *class, PyObject *
         SPECIALIZATION_FAIL(LOAD_SUPER_ATTR, SPEC_FAIL_SUPER_SHADOWED);
         goto fail;
     }
-    if (!PyType_Check(class)) {
+    if (!PyType_Check(cls)) {
         SPECIALIZATION_FAIL(LOAD_SUPER_ATTR, SPEC_FAIL_SUPER_BAD_CLASS);
         goto fail;
     }
-    PyTypeObject *tp = (PyTypeObject *)class;
+    PyTypeObject *tp = (PyTypeObject *)cls;
     PyObject *res = _PySuper_LookupDescr(tp, self, name);
     if (res == NULL) {
         SPECIALIZATION_FAIL(LOAD_SUPER_ATTR, SPEC_FAIL_SUPER_ERROR_OR_NOT_FOUND);
