May 15, 2020 · May 5, 2020 · May 5, 2020 · May 5, 2020 · May 5, 2020 · May 5, 2020
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
 name: Tests

 # bpo-40548: "paths-ignore" is not used to skip documentation-only PRs, because
 # it prevents to mark a job as mandatory. A PR cannot be merged if a job is
 # mandatory but not scheduled because of "paths-ignore".
 on:
  push:
    branches:
    - master
    - 3.8
    - 3.7
    paths-ignore:
    - 'Doc/**'
    - 'Misc/**'
    - '**/*.md'
    - '**/*.rst'
  pull_request:
    branches:
    - master
    - 3.8
    - 3.7
    paths-ignore:
    - 'Doc/**'
    - 'Misc/**'
    - '**/*.md'
    - '**/*.rst'

 jobs:
  check_source:
    name: 'Check for source changes'
    runs-on: ubuntu-latest
    outputs:
      run_tests: ${{ steps.check.outputs.run_tests }}
    steps:
      - uses: actions/checkout@v2
      - name: Check for source changes
        id: check
        run: |
          if [ -z "GITHUB_BASE_REF" ]; then
            echo '::set-output name=run_tests::true'
          else
            git fetch origin $GITHUB_BASE_REF --depth=1
            git diff --name-only origin/$GITHUB_BASE_REF... | grep -qvE '(\.rst$|^Doc|^Misc)' && echo '::set-output name=run_tests::true' || true
          fi
  build_win32:
    name: 'Windows (x86)'
    runs-on: windows-latest
    needs: check_source
    if: needs.check_source.outputs.run_tests == 'true'
    steps:
    - uses: actions/checkout@v1
    - name: Build CPython
  build_win_amd64:
    name: 'Windows (x64)'
    runs-on: windows-latest
    needs: check_source
    if: needs.check_source.outputs.run_tests == 'true'
    steps:
    - uses: actions/checkout@v1
    - name: Build CPython
  build_macos:
    name: 'macOS'
    runs-on: macos-latest
    needs: check_source
    if: needs.check_source.outputs.run_tests == 'true'
    steps:
    - uses: actions/checkout@v1
    - name: Configure CPython
  build_ubuntu:
    name: 'Ubuntu'
    runs-on: ubuntu-latest
    needs: check_source
    if: needs.check_source.outputs.run_tests == 'true'
    env:
      OPENSSL_VER: 1.1.1f
    steps:
diff --git a/Doc/c-api/structures.rst b/Doc/c-api/structures.rst
   value of the function as exposed in Python.  The function must return a new
   reference.

   The function signature is::

      PyObject *PyCFunction(PyObject *self,
                            PyObject *args);

 .. c:type:: PyCFunctionWithKeywords

   Type of the functions used to implement Python callables in C
   with signature :const:`METH_VARARGS | METH_KEYWORDS`.
   The function signature is::

      PyObject *PyCFunctionWithKeywords(PyObject *self,
                                        PyObject *args,
                                        PyObject *kwargs);


 .. c:type:: _PyCFunctionFast

   Type of the functions used to implement Python callables in C
   with signature :const:`METH_FASTCALL`.
   The function signature is::

      PyObject *_PyCFunctionFast(PyObject *self,
                                 PyObject *const *args,
                                 Py_ssize_t nargs);

 .. c:type:: _PyCFunctionFastWithKeywords

   Type of the functions used to implement Python callables in C
   with signature :const:`METH_FASTCALL | METH_KEYWORDS`.
   The function signature is::

      PyObject *_PyCFunctionFastWithKeywords(PyObject *self,
                                             PyObject *const *args,
                                             Py_ssize_t nargs,
                                             PyObject *kwnames);

 .. c:type:: PyCMethod

   Type of the functions used to implement Python callables in C
   with signature :const:`METH_METHOD | METH_FASTCALL | METH_KEYWORDS`.
   The function signature is::

      PyObject *PyCMethod(PyObject *self,
                          PyTypeObject *defining_class,
                          PyObject *const *args,
                          Py_ssize_t nargs,
                          PyObject *kwnames)

   .. versionadded:: 3.9


 .. c:type:: PyMethodDef
 The individual flags indicate either a calling convention or a binding
 convention.

 There are four basic calling conventions for positional arguments
 and two of them can be combined with :const:`METH_KEYWORDS` to support
 also keyword arguments.  So there are a total of 6 calling conventions:
 There are these calling conventions:

 .. data:: METH_VARARGS

   .. versionadded:: 3.7


 .. data:: METH_METHOD | METH_FASTCALL | METH_KEYWORDS

   Extension of :const:`METH_FASTCALL | METH_KEYWORDS` supporting the *defining
   class*, that is, the class that contains the method in question.
   The defining class might be a superclass of ``Py_TYPE(self)``.

   The method needs to be of type :c:type:`PyCMethod`, the same as for
   ``METH_FASTCALL | METH_KEYWORDS`` with ``defining_class`` argument added after
   ``self``.

   .. versionadded:: 3.9


 .. data:: METH_NOARGS

   Methods without parameters don't need to check whether arguments are given if

   Heap allocated types (created using :c:func:`PyType_FromSpec` or similar),
   ``PyMemberDef`` may contain definitions for the special members
   ``__dictoffset__`` and ``__weaklistoffset__``, corresponding to
   :c:member:`~PyTypeObject.tp_dictoffset` and
   :c:member:`~PyTypeObject.tp_weaklistoffset` in type objects.
   ``__dictoffset__``, ``__weaklistoffset__`` and ``__vectorcalloffset__``,
   corresponding to
   :c:member:`~PyTypeObject.tp_dictoffset`,
   :c:member:`~PyTypeObject.tp_weaklistoffset` and
   :c:member:`~PyTypeObject.tp_vectorcall_offset` in type objects.
   These must be defined with ``T_PYSSIZET`` and ``READONLY``, for example::

      static PyMemberDef spam_type_members[] = {
diff --git a/Doc/c-api/type.rst b/Doc/c-api/type.rst

   .. versionadded:: 3.4

 .. c:function:: PyObject* PyType_GetModule(PyTypeObject *type)

   Return the module object associated with the given type when the type was
   created using :c:func:`PyType_FromModuleAndSpec`.

   If no module is associated with the given type, sets :py:class:`TypeError`
   and returns ``NULL``.

   .. versionadded:: 3.9

 .. c:function:: void* PyType_GetModuleState(PyTypeObject *type)

   Return the state of the module object associated with the given type.
   This is a shortcut for calling :c:func:`PyModule_GetState()` on the result
   of :c:func:`PyType_GetModule`.

   If no module is associated with the given type, sets :py:class:`TypeError`
   and returns ``NULL``.

   If the *type* has an associated module but its state is ``NULL``,
   returns ``NULL`` without setting an exception.

   .. versionadded:: 3.9


 Creating Heap-Allocated Types
 .............................

 The following functions and structs are used to create
 :ref:`heap types <heap-types>`.

 .. c:function:: PyObject*PyType_FromSpecWithBases(PyType_Spec *spec, PyObject *bases)
 .. c:function:: PyObject*PyType_FromModuleAndSpec(PyObject *module,PyType_Spec *spec, PyObject *bases)

   Creates and returns a heap type object from the *spec*
   (:const:`Py_TPFLAGS_HEAPTYPE`).
   If *bases* is ``NULL``, the *Py_tp_base* slot is used instead.
   If that also is ``NULL``, the new type derives from :class:`object`.

   The *module* must be a module object or ``NULL``.
   If not ``NULL``, the module is associated with the new type and can later be
   retreived with :c:func:`PyType_GetModule`.

   This function calls :c:func:`PyType_Ready` on the new type.

   .. versionadded:: 3.9

 .. c:function:: PyObject* PyType_FromSpecWithBases(PyType_Spec *spec, PyObject *bases)

   Equivalent to ``PyType_FromModuleAndSpec(NULL, spec, bases)``.

   .. versionadded:: 3.3

 .. c:function:: PyObject* PyType_FromSpec(PyType_Spec *spec)
      * :c:member:`~PyTypeObject.tp_dictoffset`
        (see :ref:`PyMemberDef <pymemberdef-offsets>`)
      * :c:member:`~PyTypeObject.tp_vectorcall_offset`
        (see :ref:`PyMemberDef <pymemberdef-offsets>`)
      * :c:member:`~PyBufferProcs.bf_getbuffer`
      * :c:member:`~PyBufferProcs.bf_releasebuffer`

diff --git a/Doc/conf.py b/Doc/conf.py
 # ---------------------

 extensions = ['sphinx.ext.coverage', 'sphinx.ext.doctest',
              'pyspecific', 'c_annotations', 'escape4chm']
              'pyspecific', 'c_annotations', 'escape4chm',
              'asdl_highlight']


 doctest_global_setup = '''
diff --git a/Doc/library/array.rst b/Doc/library/array.rst
 +-----------+--------------------+-------------------+-----------------------+-------+
 | ``'B'``   | unsigned char      | int               | 1                     |       |
 +-----------+--------------------+-------------------+-----------------------+-------+
 | ``'u'``   |Py_UNICODE         | Unicode character | 2                     | \(1)  |
 | ``'u'``   |wchar_t         | Unicode character | 2                     | \(1)  |
 +-----------+--------------------+-------------------+-----------------------+-------+
 | ``'h'``   | signed short       | int               | 2                     |       |
 +-----------+--------------------+-------------------+-----------------------+-------+
 Notes:

 (1)
   The ``'u'`` type code corresponds to Python's obsolete unicode character
   (:c:type:`Py_UNICODE` which is :c:type:`wchar_t`). Depending on the
   platform, it can be 16 bits or 32 bits.
   It can be 16 bits or 32 bits depending on the platform.

   ``'u'`` will be removed together with the rest of the :c:type:`Py_UNICODE`
   API.
   .. versionchanged:: 3.9
      ``array('u')`` now uses ``wchar_t`` as C type instead of deprecated
      ``Py_UNICODE``. This change doesn't affect to its behavior because
      ``Py_UNICODE`` is alias of ``wchar_t`` since Python 3.3.

   .. deprecated-removed:: 3.3 4.0


 The actual representation of values is determined by the machine architecture
 (strictly speaking, by the C implementation).  The actual size can be accessed
 through the :attr:`itemsize` attribute.
diff --git a/Doc/library/ast.rst b/Doc/library/ast.rst
 The abstract grammar is currently defined as follows:

 .. literalinclude:: ../../Parser/Python.asdl
   :language:none
   :language:asdl


 Node classes
diff --git a/Doc/library/asyncio-task.rst b/Doc/library/asyncio-task.rst
          if task in done:
              # Everything will work as expected now.

   .. deprecated:: 3.8
   .. deprecated-removed:: 3.8 3.11

      Passing coroutine objects to ``wait()`` directly is
      deprecated.
diff --git a/Doc/library/code.rst b/Doc/library/code.rst

   *source* is the source string; *filename* is the optional filename from which
   source was read, defaulting to ``'<input>'``; and *symbol* is the optional
   grammar start symbol, which should beeither``'single'`` (the default) or
   ``'eval'``.
   grammar start symbol, which should be ``'single'`` (the default), ``'eval'``
 or``'exec'``.

   Returns a code object (the same as ``compile(source, filename, symbol)``) if the
   command is complete and valid; ``None`` if the command is incomplete; raises
diff --git a/Doc/library/codeop.rst b/Doc/library/codeop.rst
   :exc:`OverflowError` or :exc:`ValueError` if there is an invalid literal.

   The *symbol* argument determines whether *source* is compiled as a statement
   (``'single'``, the default) or as an :term:`expression` (``'eval'``).  Any
   other value will cause :exc:`ValueError` to  be raised.
   (``'single'``, the default), as a sequence of statements (``'exec'``) or
   as an :term:`expression` (``'eval'``).  Any other value will
   cause :exc:`ValueError` to  be raised.

   .. note::
Original file line number	Diff line number	Diff line change
		@@ -1,31 +1,42 @@
		name: Tests

		# bpo-40548: "paths-ignore" is not used to skip documentation-only PRs, because
		# it prevents to mark a job as mandatory. A PR cannot be merged if a job is
		# mandatory but not scheduled because of "paths-ignore".
		on:
		push:
		branches:
		- master
		- 3.8
		- 3.7
		paths-ignore:
		- 'Doc/**'
		- 'Misc/**'
		- '*/.md'
		- '*/.rst'
		pull_request:
		branches:
		- master
		- 3.8
		- 3.7
		paths-ignore:
		- 'Doc/**'
		- 'Misc/**'
		- '*/.md'
		- '*/.rst'

		jobs:
		check_source:
		name: 'Check for source changes'
		runs-on: ubuntu-latest
		outputs:
		run_tests: ${{ steps.check.outputs.run_tests }}
		steps:
		- uses: actions/checkout@v2
		- name: Check for source changes
		id: check
		run: \|
		if [ -z "GITHUB_BASE_REF" ]; then
		echo '::set-output name=run_tests::true'
		else
		git fetch origin $GITHUB_BASE_REF --depth=1
		git diff --name-only origin/$GITHUB_BASE_REF... \| grep -qvE '(\.rst$\|^Doc\|^Misc)' && echo '::set-output name=run_tests::true' \|\| true
		fi
		build_win32:
		name: 'Windows (x86)'
		runs-on: windows-latest
		needs: check_source
		if: needs.check_source.outputs.run_tests == 'true'
		steps:
		- uses: actions/checkout@v1
		- name: Build CPython
Expand All		@@ -38,6 +49,8 @@ jobs:
		build_win_amd64:
		name: 'Windows (x64)'
		runs-on: windows-latest
		needs: check_source
		if: needs.check_source.outputs.run_tests == 'true'
		steps:
		- uses: actions/checkout@v1
		- name: Build CPython
Expand All		@@ -50,6 +63,8 @@ jobs:
		build_macos:
		name: 'macOS'
		runs-on: macos-latest
		needs: check_source
		if: needs.check_source.outputs.run_tests == 'true'
		steps:
		- uses: actions/checkout@v1
		- name: Configure CPython
Expand All		@@ -64,6 +79,8 @@ jobs:
		build_ubuntu:
		name: 'Ubuntu'
		runs-on: ubuntu-latest
		needs: check_source
		if: needs.check_source.outputs.run_tests == 'true'
		env:
		OPENSSL_VER: 1.1.1f
		steps:
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -147,23 +147,56 @@ Implementing functions and methods
		value of the function as exposed in Python. The function must return a new
		reference.

		The function signature is::

		PyObject PyCFunction(PyObject self,
		PyObject *args);

		.. c:type:: PyCFunctionWithKeywords

		Type of the functions used to implement Python callables in C
		with signature :const:`METH_VARARGS \| METH_KEYWORDS`.
		The function signature is::

		PyObject PyCFunctionWithKeywords(PyObject self,
		PyObject *args,
		PyObject *kwargs);


		.. c:type:: _PyCFunctionFast

		Type of the functions used to implement Python callables in C
		with signature :const:`METH_FASTCALL`.
		The function signature is::

		PyObject _PyCFunctionFast(PyObject self,
		PyObject const args,
		Py_ssize_t nargs);

		.. c:type:: _PyCFunctionFastWithKeywords

		Type of the functions used to implement Python callables in C
		with signature :const:`METH_FASTCALL \| METH_KEYWORDS`.
		The function signature is::

		PyObject _PyCFunctionFastWithKeywords(PyObject self,
		PyObject const args,
		Py_ssize_t nargs,
		PyObject *kwnames);

		.. c:type:: PyCMethod

		Type of the functions used to implement Python callables in C
		with signature :const:`METH_METHOD \| METH_FASTCALL \| METH_KEYWORDS`.
		The function signature is::

		PyObject PyCMethod(PyObject self,
		PyTypeObject *defining_class,
		PyObject const args,
		Py_ssize_t nargs,
		PyObject *kwnames)

		.. versionadded:: 3.9


		.. c:type:: PyMethodDef
Expand DownExpand Up		@@ -197,9 +230,7 @@ The :attr:`ml_flags` field is a bitfield which can include the following flags.
		The individual flags indicate either a calling convention or a binding
		convention.

		There are four basic calling conventions for positional arguments
		and two of them can be combined with :const:`METH_KEYWORDS` to support
		also keyword arguments. So there are a total of 6 calling conventions:
		There are these calling conventions:

		.. data:: METH_VARARGS

Expand DownExpand Up		@@ -250,6 +281,19 @@ also keyword arguments. So there are a total of 6 calling conventions:
		.. versionadded:: 3.7


		.. data:: METH_METHOD \| METH_FASTCALL \| METH_KEYWORDS

		Extension of :const:`METH_FASTCALL \| METH_KEYWORDS` supporting the *defining
		class*, that is, the class that contains the method in question.
		The defining class might be a superclass of ``Py_TYPE(self)``.

		The method needs to be of type :c:type:`PyCMethod`, the same as for
		``METH_FASTCALL \| METH_KEYWORDS`` with ``defining_class`` argument added after
		``self``.

		.. versionadded:: 3.9


		.. data:: METH_NOARGS

		Methods without parameters don't need to check whether arguments are given if
Expand DownExpand Up		@@ -380,9 +424,11 @@ Accessing attributes of extension types

		Heap allocated types (created using :c:func:`PyType_FromSpec` or similar),
		``PyMemberDef`` may contain definitions for the special members
		``__dictoffset__`` and ``__weaklistoffset__``, corresponding to
		:c:member:`~PyTypeObject.tp_dictoffset` and
		:c:member:`~PyTypeObject.tp_weaklistoffset` in type objects.
		``__dictoffset__``, ``__weaklistoffset__`` and ``__vectorcalloffset__``,
		corresponding to
		:c:member:`~PyTypeObject.tp_dictoffset`,
		:c:member:`~PyTypeObject.tp_weaklistoffset` and
		:c:member:`~PyTypeObject.tp_vectorcall_offset` in type objects.
		These must be defined with ``T_PYSSIZET`` and ``READONLY``, for example::

		static PyMemberDef spam_type_members[] = {
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -109,14 +109,38 @@ Type Objects

		.. versionadded:: 3.4

		.. c:function:: PyObject* PyType_GetModule(PyTypeObject *type)

		Return the module object associated with the given type when the type was
		created using :c:func:`PyType_FromModuleAndSpec`.

		If no module is associated with the given type, sets :py:class:`TypeError`
		and returns ``NULL``.

		.. versionadded:: 3.9

		.. c:function:: void* PyType_GetModuleState(PyTypeObject *type)

		Return the state of the module object associated with the given type.
		This is a shortcut for calling :c:func:`PyModule_GetState()` on the result
		of :c:func:`PyType_GetModule`.

		If no module is associated with the given type, sets :py:class:`TypeError`
		and returns ``NULL``.

		If the type has an associated module but its state is ``NULL``,
		returns ``NULL`` without setting an exception.

		.. versionadded:: 3.9


		Creating Heap-Allocated Types
		.............................

		The following functions and structs are used to create
		:ref:`heap types <heap-types>`.

		.. c:function:: PyObjectPyType_FromSpecWithBases(PyType_Spec spec, PyObject *bases)
		.. c:function:: PyObjectPyType_FromModuleAndSpec(PyObject module,PyType_Spec spec, PyObject bases)

		Creates and returns a heap type object from the spec
		(:const:`Py_TPFLAGS_HEAPTYPE`).
Expand All		@@ -127,8 +151,18 @@ The following functions and structs are used to create
		If bases is ``NULL``, the Py_tp_base slot is used instead.
		If that also is ``NULL``, the new type derives from :class:`object`.

		The module must be a module object or ``NULL``.
		If not ``NULL``, the module is associated with the new type and can later be
		retreived with :c:func:`PyType_GetModule`.

		This function calls :c:func:`PyType_Ready` on the new type.

		.. versionadded:: 3.9

		.. c:function:: PyObject* PyType_FromSpecWithBases(PyType_Spec spec, PyObject bases)

		Equivalent to ``PyType_FromModuleAndSpec(NULL, spec, bases)``.

		.. versionadded:: 3.3

		.. c:function:: PyObject* PyType_FromSpec(PyType_Spec *spec)
Expand DownExpand Up		@@ -194,6 +228,7 @@ The following functions and structs are used to create
		* :c:member:`~PyTypeObject.tp_dictoffset`
		(see :ref:`PyMemberDef <pymemberdef-offsets>`)
		* :c:member:`~PyTypeObject.tp_vectorcall_offset`
		(see :ref:`PyMemberDef <pymemberdef-offsets>`)
		* :c:member:`~PyBufferProcs.bf_getbuffer`
		* :c:member:`~PyBufferProcs.bf_releasebuffer`

Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -14,7 +14,8 @@
		# ---------------------

		extensions = ['sphinx.ext.coverage', 'sphinx.ext.doctest',
		'pyspecific', 'c_annotations', 'escape4chm']
		'pyspecific', 'c_annotations', 'escape4chm',
		'asdl_highlight']


		doctest_global_setup = '''
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -22,7 +22,7 @@ defined:
		+-----------+--------------------+-------------------+-----------------------+-------+
		\| ``'B'`` \| unsigned char \| int \| 1 \| \|
		+-----------+--------------------+-------------------+-----------------------+-------+
		\| ``'u'`` \|Py_UNICODE \| Unicode character \| 2 \| \(1) \|
		\| ``'u'`` \|wchar_t \| Unicode character \| 2 \| \(1) \|
		+-----------+--------------------+-------------------+-----------------------+-------+
		\| ``'h'`` \| signed short \| int \| 2 \| \|
		+-----------+--------------------+-------------------+-----------------------+-------+
Expand All		@@ -48,15 +48,16 @@ defined:
		Notes:

		(1)
		The ``'u'`` type code corresponds to Python's obsolete unicode character
		(:c:type:`Py_UNICODE` which is :c:type:`wchar_t`). Depending on the
		platform, it can be 16 bits or 32 bits.
		It can be 16 bits or 32 bits depending on the platform.

		``'u'`` will be removed together with the rest of the :c:type:`Py_UNICODE`
		API.
		.. versionchanged:: 3.9
		``array('u')`` now uses ``wchar_t`` as C type instead of deprecated
		``Py_UNICODE``. This change doesn't affect to its behavior because
		``Py_UNICODE`` is alias of ``wchar_t`` since Python 3.3.

		.. deprecated-removed:: 3.3 4.0


		The actual representation of values is determined by the machine architecture
		(strictly speaking, by the C implementation). The actual size can be accessed
		through the :attr:`itemsize` attribute.
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -35,7 +35,7 @@ Abstract Grammar
		The abstract grammar is currently defined as follows:

		.. literalinclude:: ../../Parser/Python.asdl
		:language:none
		:language:asdl


		Node classes
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -575,7 +575,7 @@ Waiting Primitives
		if task in done:
		# Everything will work as expected now.

		.. deprecated:: 3.8
		.. deprecated-removed:: 3.8 3.11

		Passing coroutine objects to ``wait()`` directly is
		deprecated.
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -56,8 +56,8 @@ build applications which provide an interactive interpreter prompt.

		source is the source string; filename is the optional filename from which
		source was read, defaulting to ``'<input>'``; and symbol is the optional
		grammar start symbol, which should beeither``'single'`` (the default) or
		``'eval'``.
		grammar start symbol, which should be ``'single'`` (the default), ``'eval'``
		or``'exec'``.

		Returns a code object (the same as ``compile(source, filename, symbol)``) if the
		command is complete and valid; ``None`` if the command is incomplete; raises
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -43,8 +43,9 @@ To do just the former:
		:exc:`OverflowError` or :exc:`ValueError` if there is an invalid literal.

		The symbol argument determines whether source is compiled as a statement
		(``'single'``, the default) or as an :term:`expression` (``'eval'``). Any
		other value will cause :exc:`ValueError` to be raised.
		(``'single'``, the default), as a sequence of statements (``'exec'``) or
		as an :term:`expression` (``'eval'``). Any other value will
		cause :exc:`ValueError` to be raised.

		.. note::

Expand Down