Skip to content

Commit

Permalink
Merge branch 'main' into simpler-fix-for-eager-staggered-race
Browse files Browse the repository at this point in the history
  • Loading branch information
graingert authored Oct 8, 2024
2 parents 2c928f6 + 19984fe commit ef65dbf
Show file tree
Hide file tree
Showing 217 changed files with 12,086 additions and 15,173 deletions.
9 changes: 6 additions & 3 deletions Doc/c-api/code.rst
Original file line number Diff line number Diff line change
Expand Up @@ -32,11 +32,13 @@ bound into a function.
.. c:function:: Py_ssize_t PyCode_GetNumFree(PyCodeObject *co)
Return the number of free variables in a code object.
Return the number of :term:`free (closure) variables <closure variable>`
in a code object.
.. c:function:: int PyUnstable_Code_GetFirstFree(PyCodeObject *co)
Return the position of the first free variable in a code object.
Return the position of the first :term:`free (closure) variable <closure variable>`
in a code object.
.. versionchanged:: 3.13
Expand Down Expand Up @@ -144,7 +146,8 @@ bound into a function.
Equivalent to the Python code ``getattr(co, 'co_freevars')``.
Returns a new reference to a :c:type:`PyTupleObject` containing the names of
the free variables. On error, ``NULL`` is returned and an exception is raised.
the :term:`free (closure) variables <closure variable>`. On error, ``NULL`` is returned
and an exception is raised.
.. versionadded:: 3.11
Expand Down
240 changes: 203 additions & 37 deletions Doc/c-api/init.rst

Large diffs are not rendered by default.

29 changes: 4 additions & 25 deletions Doc/c-api/init_config.rst
Original file line number Diff line number Diff line change
Expand Up @@ -1356,14 +1356,13 @@ the :option:`-X` command line option.
The ``show_alloc_count`` field has been removed.
.. _init-from-config:
Initialization with PyConfig
----------------------------
Function to initialize Python:
.. c:function:: PyStatus Py_InitializeFromConfig(const PyConfig *config)
Initialize Python from *config* configuration.
Initializing the interpreter from a populated configuration struct is handled
by calling :c:func:`Py_InitializeFromConfig`.
The caller is responsible to handle exceptions (error or exit) using
:c:func:`PyStatus_Exception` and :c:func:`Py_ExitStatusException`.
Expand Down Expand Up @@ -1835,26 +1834,6 @@ return ``-1`` on error:
}
Py_RunMain()
============
.. c:function:: int Py_RunMain(void)
Execute the command (:c:member:`PyConfig.run_command`), the script
(:c:member:`PyConfig.run_filename`) or the module
(:c:member:`PyConfig.run_module`) specified on the command line or in the
configuration.
By default and when if :option:`-i` option is used, run the REPL.
Finally, finalizes Python and returns an exit status that can be passed to
the ``exit()`` function.
See :ref:`Python Configuration <init-python-config>` for an example of
customized Python always running in isolated mode using
:c:func:`Py_RunMain`.
Runtime Python configuration API
================================
Expand Down
3 changes: 2 additions & 1 deletion Doc/c-api/tuple.rst
Original file line number Diff line number Diff line change
Expand Up @@ -167,7 +167,8 @@ type.
.. c:member:: const char *name
Name of the struct sequence type.
Fully qualified name of the type; null-terminated UTF-8 encoded.
The name must contain the module name.
.. c:member:: const char *doc
Expand Down
25 changes: 25 additions & 0 deletions Doc/c-api/unicode.rst
Original file line number Diff line number Diff line change
Expand Up @@ -1438,6 +1438,31 @@ They all return ``NULL`` or ``-1`` if an exception occurs.
This function returns ``-1`` upon failure, so one should call
:c:func:`PyErr_Occurred` to check for errors.
.. seealso::
The :c:func:`PyUnicode_Equal` function.
.. c:function:: int PyUnicode_Equal(PyObject *a, PyObject *b)
Test if two strings are equal:
* Return ``1`` if *a* is equal to *b*.
* Return ``0`` if *a* is not equal to *b*.
* Set a :exc:`TypeError` exception and return ``-1`` if *a* or *b* is not a
:class:`str` object.
The function always succeeds if *a* and *b* are :class:`str` objects.
The function works for :class:`str` subclasses, but does not honor custom
``__eq__()`` method.
.. seealso::
The :c:func:`PyUnicode_Compare` function.
.. versionadded:: 3.14
.. c:function:: int PyUnicode_EqualToUTF8AndSize(PyObject *unicode, const char *string, Py_ssize_t size)
Expand Down
24 changes: 0 additions & 24 deletions Doc/c-api/veryhigh.rst
Original file line number Diff line number Diff line change
Expand Up @@ -25,30 +25,6 @@ are only passed to these functions if it is certain that they were created by
the same library that the Python runtime is using.


.. c:function:: int Py_Main(int argc, wchar_t **argv)
The main program for the standard interpreter. This is made available for
programs which embed Python. The *argc* and *argv* parameters should be
prepared exactly as those which are passed to a C program's :c:func:`main`
function (converted to wchar_t according to the user's locale). It is
important to note that the argument list may be modified (but the contents of
the strings pointed to by the argument list are not). The return value will
be ``0`` if the interpreter exits normally (i.e., without an exception),
``1`` if the interpreter exits due to an exception, or ``2`` if the parameter
list does not represent a valid Python command line.
Note that if an otherwise unhandled :exc:`SystemExit` is raised, this
function will not return ``1``, but exit the process, as long as
:c:member:`PyConfig.inspect` is zero.
.. c:function:: int Py_BytesMain(int argc, char **argv)
Similar to :c:func:`Py_Main` but *argv* is an array of bytes strings.
.. versionadded:: 3.8
.. c:function:: int PyRun_AnyFile(FILE *fp, const char *filename)
This is a simplified interface to :c:func:`PyRun_AnyFileExFlags` below, leaving
Expand Down
1 change: 1 addition & 0 deletions Doc/data/stable_abi.dat

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

43 changes: 34 additions & 9 deletions Doc/glossary.rst
Original file line number Diff line number Diff line change
Expand Up @@ -231,6 +231,28 @@ Glossary
A variable defined in a class and intended to be modified only at
class level (i.e., not in an instance of the class).

closure variable
A :term:`free variable` referenced from a :term:`nested scope` that is defined in an outer
scope rather than being resolved at runtime from the globals or builtin namespaces.
May be explicitly defined with the :keyword:`nonlocal` keyword to allow write access,
or implicitly defined if the variable is only being read.

For example, in the ``inner`` function in the following code, both ``x`` and ``print`` are
:term:`free variables <free variable>`, but only ``x`` is a *closure variable*::

def outer():
x = 0
def inner():
nonlocal x
x += 1
print(x)
return inner

Due to the :attr:`codeobject.co_freevars` attribute (which, despite its name, only
includes the names of closure variables rather than listing all referenced free
variables), the more general :term:`free variable` term is sometimes used even
when the intended meaning is to refer specifically to closure variables.

complex number
An extension of the familiar real number system in which all numbers are
expressed as a sum of a real part and an imaginary part. Imaginary
Expand Down Expand Up @@ -454,6 +476,13 @@ Glossary
the :term:`global interpreter lock` which allows only one thread to
execute Python bytecode at a time. See :pep:`703`.

free variable
Formally, as defined in the :ref:`language execution model <bind_names>`, a free
variable is any variable used in a namespace which is not a local variable in that
namespace. See :term:`closure variable` for an example.
Pragmatically, due to the name of the :attr:`codeobject.co_freevars` attribute,
the term is also sometimes used as a synonym for :term:`closure variable`.

function
A series of statements which returns some value to a caller. It can also
be passed zero or more :term:`arguments <argument>` which may be used in
Expand Down Expand Up @@ -1160,16 +1189,12 @@ Glossary
(subscript) notation uses :class:`slice` objects internally.

soft deprecated
A soft deprecation can be used when using an API which should no longer
be used to write new code, but it remains safe to continue using it in
existing code. The API remains documented and tested, but will not be
developed further (no enhancement).

The main difference between a "soft" and a (regular) "hard" deprecation
is that the soft deprecation does not imply scheduling the removal of the
deprecated API.
A soft deprecated API should not be used in new code,
but it is safe for already existing code to use it.
The API remains documented and tested, but will not be enhanced further.

Another difference is that a soft deprecation does not issue a warning.
Soft deprecation, unlike normal deprecation, does not plan on removing the API
and will not emit warnings.

See `PEP 387: Soft Deprecation
<https://peps.python.org/pep-0387/#soft-deprecation>`_.
Expand Down
9 changes: 2 additions & 7 deletions Doc/library/_thread.rst
Original file line number Diff line number Diff line change
Expand Up @@ -213,9 +213,8 @@ In addition to these methods, lock objects can also be used via the

.. index:: pair: module; signal

* Threads interact strangely with interrupts: the :exc:`KeyboardInterrupt`
exception will be received by an arbitrary thread. (When the :mod:`signal`
module is available, interrupts always go to the main thread.)
* Interrupts always go to the main thread (the :exc:`KeyboardInterrupt`
exception will be received by that thread.)

* Calling :func:`sys.exit` or raising the :exc:`SystemExit` exception is
equivalent to calling :func:`_thread.exit`.
Expand All @@ -229,7 +228,3 @@ In addition to these methods, lock objects can also be used via the
:keyword:`try` ... :keyword:`finally` clauses or executing object
destructors.

* When the main thread exits, it does not do any of its usual cleanup (except
that :keyword:`try` ... :keyword:`finally` clauses are honored), and the
standard I/O files are not flushed.

41 changes: 32 additions & 9 deletions Doc/library/argparse.rst
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ Quick Links for ArgumentParser
========================= =========================================================================================================== ==================================================================================
Name Description Values
========================= =========================================================================================================== ==================================================================================
prog_ The name of the program Defaults to ``os.path.basename(sys.argv[0])``
prog_ The name of the program
usage_ The string describing the program usage
description_ A brief description of what the program does
epilog_ Additional description of the program after the argument help
Expand Down Expand Up @@ -214,8 +214,8 @@ ArgumentParser objects
as keyword arguments. Each parameter has its own more detailed description
below, but in short they are:

* prog_ - The name of the program (default:
``os.path.basename(sys.argv[0])``)
* prog_ - The name of the program (default: generated from the ``__main__``
module attributes and ``sys.argv[0]``)

* usage_ - The string describing the program usage (default: generated from
arguments added to parser)
Expand Down Expand Up @@ -268,10 +268,18 @@ The following sections describe how each of these are used.
prog
^^^^

By default, :class:`ArgumentParser` objects use the base name
(see :func:`os.path.basename`) of ``sys.argv[0]`` to determine
how to display the name of the program in help messages. This default is almost
always desirable because it will make the help messages match the name that was
By default, :class:`ArgumentParser` calculates the name of the program
to display in help messages depending on the way the Python inerpreter was run:

* The :func:`base name <os.path.basename>` of ``sys.argv[0]`` if a file was
passed as argument.
* The Python interpreter name followed by ``sys.argv[0]`` if a directory or
a zipfile was passed as argument.
* The Python interpreter name followed by ``-m`` followed by the
module or package name if the :option:`-m` option was used.

This default is almost
always desirable because it will make the help messages match the string that was
used to invoke the program on the command line. For example, consider a file
named ``myprogram.py`` with the following code::

Expand All @@ -281,7 +289,7 @@ named ``myprogram.py`` with the following code::
args = parser.parse_args()

The help for this program will display ``myprogram.py`` as the program name
(regardless of where the program was invoked from):
(regardless of where the program was invoked from) if it is run as a script:

.. code-block:: shell-session
Expand All @@ -299,6 +307,17 @@ The help for this program will display ``myprogram.py`` as the program name
-h, --help show this help message and exit
--foo FOO foo help
If it is executed via the :option:`-m` option, the help will display a corresponding command line:

.. code-block:: shell-session
$ /usr/bin/python3 -m subdir.myprogram --help
usage: python3 -m subdir.myprogram [-h] [--foo FOO]
options:
-h, --help show this help message and exit
--foo FOO foo help
To change this default behavior, another value can be supplied using the
``prog=`` argument to :class:`ArgumentParser`::

Expand All @@ -309,7 +328,8 @@ To change this default behavior, another value can be supplied using the
options:
-h, --help show this help message and exit

Note that the program name, whether determined from ``sys.argv[0]`` or from the
Note that the program name, whether determined from ``sys.argv[0]``,
from the ``__main__`` module attributes or from the
``prog=`` argument, is available to help messages using the ``%(prog)s`` format
specifier.

Expand All @@ -324,6 +344,9 @@ specifier.
-h, --help show this help message and exit
--foo FOO foo of the myprogram program

.. versionchanged:: 3.14
The default ``prog`` value now reflects how ``__main__`` was actually executed,
rather than always being ``os.path.basename(sys.argv[0])``.

usage
^^^^^
Expand Down
10 changes: 9 additions & 1 deletion Doc/library/dataclasses.rst
Original file line number Diff line number Diff line change
Expand Up @@ -399,7 +399,7 @@ Module contents
:func:`!astuple` raises :exc:`TypeError` if *obj* is not a dataclass
instance.

.. function:: make_dataclass(cls_name, fields, *, bases=(), namespace=None, init=True, repr=True, eq=True, order=False, unsafe_hash=False, frozen=False, match_args=True, kw_only=False, slots=False, weakref_slot=False, module=None)
.. function:: make_dataclass(cls_name, fields, *, bases=(), namespace=None, init=True, repr=True, eq=True, order=False, unsafe_hash=False, frozen=False, match_args=True, kw_only=False, slots=False, weakref_slot=False, module=None, decorator=dataclass)

Creates a new dataclass with name *cls_name*, fields as defined
in *fields*, base classes as given in *bases*, and initialized
Expand All @@ -415,6 +415,11 @@ Module contents
of the dataclass is set to that value.
By default, it is set to the module name of the caller.

The *decorator* parameter is a callable that will be used to create the dataclass.
It should take the class object as a first argument and the same keyword arguments
as :func:`@dataclass <dataclass>`. By default, the :func:`@dataclass <dataclass>`
function is used.

This function is not strictly required, because any Python
mechanism for creating a new class with :attr:`!__annotations__` can
then apply the :func:`@dataclass <dataclass>` function to convert that class to
Expand All @@ -438,6 +443,9 @@ Module contents
def add_one(self):
return self.x + 1

.. versionadded:: 3.14
Added the *decorator* parameter.

.. function:: replace(obj, /, **changes)

Creates a new object of the same type as *obj*, replacing
Expand Down
16 changes: 15 additions & 1 deletion Doc/library/datetime.rst
Original file line number Diff line number Diff line change
Expand Up @@ -295,6 +295,20 @@ Instance attributes (read-only):

Between 0 and 86,399 inclusive.

.. caution::

It is a somewhat common bug for code to unintentionally use this attribute
when it is actually intended to get a :meth:`~timedelta.total_seconds`
value instead:

.. doctest::

>>> from datetime import timedelta
>>> duration = timedelta(seconds=11235813)
>>> duration.days, duration.seconds
(130, 3813)
>>> duration.total_seconds()
11235813.0

.. attribute:: timedelta.microseconds

Expand Down Expand Up @@ -351,7 +365,7 @@ Supported operations:
| | same value. (2) |
+--------------------------------+-----------------------------------------------+
| ``-t1`` | Equivalent to ``timedelta(-t1.days, |
| | -t1.seconds*, -t1.microseconds)``, |
| | -t1.seconds, -t1.microseconds)``, |
| | and to ``t1 * -1``. (1)(4) |
+--------------------------------+-----------------------------------------------+
| ``abs(t)`` | Equivalent to ``+t`` when ``t.days >= 0``, |
Expand Down
Loading

0 comments on commit ef65dbf

Please sign in to comment.