aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/Doc
diff options
context:
space:
mode:
Diffstat (limited to 'Doc')
-rw-r--r--Doc/c-api/exceptions.rst10
-rw-r--r--Doc/c-api/refcounting.rst2
-rw-r--r--Doc/c-api/type.rst4
-rw-r--r--Doc/conf.py4
-rw-r--r--Doc/data/refcounts.dat4
-rw-r--r--Doc/howto/free-threading-extensions.rst4
-rw-r--r--Doc/howto/free-threading-python.rst17
-rw-r--r--Doc/howto/regex.rst8
-rw-r--r--Doc/library/concurrent.futures.rst19
-rw-r--r--Doc/library/ctypes.rst2
-rw-r--r--Doc/library/dialog.rst2
-rw-r--r--Doc/library/dis.rst8
-rw-r--r--Doc/library/email.header.rst34
-rw-r--r--Doc/library/logging.config.rst2
-rw-r--r--Doc/library/pkgutil.rst4
-rw-r--r--Doc/library/shutil.rst4
-rw-r--r--Doc/library/sqlite3.rst9
-rw-r--r--Doc/library/sys.rst13
-rw-r--r--Doc/library/threading.rst2
-rw-r--r--Doc/library/uuid.rst29
-rw-r--r--Doc/library/zoneinfo.rst4
-rw-r--r--Doc/reference/datamodel.rst2
-rw-r--r--Doc/reference/expressions.rst3
-rw-r--r--Doc/reference/lexical_analysis.rst218
-rw-r--r--Doc/using/configure.rst4
-rw-r--r--Doc/using/mac.rst113
-rw-r--r--Doc/whatsnew/3.14.rst43
27 files changed, 385 insertions, 183 deletions
diff --git a/Doc/c-api/exceptions.rst b/Doc/c-api/exceptions.rst
index 885dbeb7530..a750cda3e2d 100644
--- a/Doc/c-api/exceptions.rst
+++ b/Doc/c-api/exceptions.rst
@@ -749,6 +749,16 @@ Exception Classes
.. versionadded:: 3.2
+.. c:function:: int PyExceptionClass_Check(PyObject *ob)
+
+ Return non-zero if *ob* is an exception class, zero otherwise. This function always succeeds.
+
+
+.. c:function:: const char *PyExceptionClass_Name(PyObject *ob)
+
+ Return :c:member:`~PyTypeObject.tp_name` of the exception class *ob*.
+
+
Exception Objects
=================
diff --git a/Doc/c-api/refcounting.rst b/Doc/c-api/refcounting.rst
index b23f016f9b0..57a0728d4e9 100644
--- a/Doc/c-api/refcounting.rst
+++ b/Doc/c-api/refcounting.rst
@@ -210,7 +210,7 @@ of Python objects.
Py_SETREF(dst, src);
- That arranges to set *dst* to *src* _before_ releasing the reference
+ That arranges to set *dst* to *src* *before* releasing the reference
to the old value of *dst*, so that any code triggered as a side-effect
of *dst* getting torn down no longer believes *dst* points
to a valid object.
diff --git a/Doc/c-api/type.rst b/Doc/c-api/type.rst
index 2176b8e492f..5bdbff4e0ad 100644
--- a/Doc/c-api/type.rst
+++ b/Doc/c-api/type.rst
@@ -282,6 +282,10 @@ Type Objects
and other places where a method's defining class cannot be passed using the
:c:type:`PyCMethod` calling convention.
+ The returned reference is :term:`borrowed <borrowed reference>` from *type*,
+ and will be valid as long as you hold a reference to *type*.
+ Do not release it with :c:func:`Py_DECREF` or similar.
+
.. versionadded:: 3.11
.. c:function:: int PyType_GetBaseByToken(PyTypeObject *type, void *token, PyTypeObject **result)
diff --git a/Doc/conf.py b/Doc/conf.py
index b08f5452901..161c2986441 100644
--- a/Doc/conf.py
+++ b/Doc/conf.py
@@ -79,6 +79,10 @@ version, release = import_module('patchlevel').get_version_info()
rst_epilog = f"""
.. |python_version_literal| replace:: ``Python {version}``
.. |python_x_dot_y_literal| replace:: ``python{version}``
+.. |python_x_dot_y_t_literal| replace:: ``python{version}t``
+.. |python_x_dot_y_t_literal_config| replace:: ``python{version}t-config``
+.. |x_dot_y_b2_literal| replace:: ``{version}.0b2``
+.. |applications_python_version_literal| replace:: ``/Applications/Python {version}/``
.. |usr_local_bin_python_x_dot_y_literal| replace:: ``/usr/local/bin/python{version}``
.. Apparently this how you hack together a formatted link:
diff --git a/Doc/data/refcounts.dat b/Doc/data/refcounts.dat
index f5f02f0a79c..99cc823c0c3 100644
--- a/Doc/data/refcounts.dat
+++ b/Doc/data/refcounts.dat
@@ -2385,6 +2385,10 @@ PyType_GetFlags:PyTypeObject*:type:0:
PyType_GetName:PyObject*::+1:
PyType_GetName:PyTypeObject*:type:0:
+PyType_GetModuleByDef:PyObject*::0:
+PyType_GetModuleByDef:PyTypeObject*:type:0:
+PyType_GetModuleByDef:PyModuleDef*:def::
+
PyType_GetQualName:PyObject*::+1:
PyType_GetQualName:PyTypeObject*:type:0:
diff --git a/Doc/howto/free-threading-extensions.rst b/Doc/howto/free-threading-extensions.rst
index 175bb5dc831..02b45879ccf 100644
--- a/Doc/howto/free-threading-extensions.rst
+++ b/Doc/howto/free-threading-extensions.rst
@@ -6,8 +6,8 @@
C API Extension Support for Free Threading
******************************************
-Starting with the 3.13 release, CPython has experimental support for running
-with the :term:`global interpreter lock` (GIL) disabled in a configuration
+Starting with the 3.13 release, CPython has support for running with
+the :term:`global interpreter lock` (GIL) disabled in a configuration
called :term:`free threading`. This document describes how to adapt C API
extensions to support free threading.
diff --git a/Doc/howto/free-threading-python.rst b/Doc/howto/free-threading-python.rst
index c33cef2c8e9..24069617c47 100644
--- a/Doc/howto/free-threading-python.rst
+++ b/Doc/howto/free-threading-python.rst
@@ -1,18 +1,21 @@
.. _freethreading-python-howto:
-**********************************************
-Python experimental support for free threading
-**********************************************
+*********************************
+Python support for free threading
+*********************************
-Starting with the 3.13 release, CPython has experimental support for a build of
+Starting with the 3.13 release, CPython has support for a build of
Python called :term:`free threading` where the :term:`global interpreter lock`
(GIL) is disabled. Free-threaded execution allows for full utilization of the
available processing power by running threads in parallel on available CPU cores.
While not all software will benefit from this automatically, programs
designed with threading in mind will run faster on multi-core hardware.
-**The free-threaded mode is experimental** and work is ongoing to improve it:
-expect some bugs and a substantial single-threaded performance hit.
+The free-threaded mode is working and continues to be improved, but
+there is some additional overhead in single-threaded workloads compared
+to the regular build. Additionally, third-party packages, in particular ones
+with an :term:`extension module`, may not be ready for use in a
+free-threaded build, and will re-enable the :term:`GIL`.
This document describes the implications of free threading
for Python code. See :ref:`freethreading-extensions-howto` for information on
@@ -43,7 +46,7 @@ Identifying free-threaded Python
================================
To check if the current interpreter supports free-threading, :option:`python -VV <-V>`
-and :data:`sys.version` contain "experimental free-threading build".
+and :data:`sys.version` contain "free-threading build".
The new :func:`sys._is_gil_enabled` function can be used to check whether
the GIL is actually disabled in the running process.
diff --git a/Doc/howto/regex.rst b/Doc/howto/regex.rst
index e543f6d5657..7486a378dbb 100644
--- a/Doc/howto/regex.rst
+++ b/Doc/howto/regex.rst
@@ -1016,7 +1016,9 @@ extension. This regular expression matches ``foo.bar`` and
Now, consider complicating the problem a bit; what if you want to match
filenames where the extension is not ``bat``? Some incorrect attempts:
-``.*[.][^b].*$`` The first attempt above tries to exclude ``bat`` by requiring
+``.*[.][^b].*$``
+
+The first attempt above tries to exclude ``bat`` by requiring
that the first character of the extension is not a ``b``. This is wrong,
because the pattern also doesn't match ``foo.bar``.
@@ -1043,7 +1045,9 @@ confusing.
A negative lookahead cuts through all this confusion:
-``.*[.](?!bat$)[^.]*$`` The negative lookahead means: if the expression ``bat``
+``.*[.](?!bat$)[^.]*$``
+
+The negative lookahead means: if the expression ``bat``
doesn't match at this point, try the rest of the pattern; if ``bat$`` does
match, the whole pattern will fail. The trailing ``$`` is required to ensure
that something like ``sample.batch``, where the extension only starts with
diff --git a/Doc/library/concurrent.futures.rst b/Doc/library/concurrent.futures.rst
index 3c8d9ab111e..dd92765038c 100644
--- a/Doc/library/concurrent.futures.rst
+++ b/Doc/library/concurrent.futures.rst
@@ -265,7 +265,7 @@ Each worker's interpreter is isolated from all the other interpreters.
"Isolated" means each interpreter has its own runtime state and
operates completely independently. For example, if you redirect
:data:`sys.stdout` in one interpreter, it will not be automatically
-redirected any other interpreter. If you import a module in one
+redirected to any other interpreter. If you import a module in one
interpreter, it is not automatically imported in any other. You
would need to import the module separately in interpreter where
you need it. In fact, each module imported in an interpreter is
@@ -287,7 +287,7 @@ efficient alternative is to serialize with :mod:`pickle` and then send
the bytes over a shared :mod:`socket <socket>` or
:func:`pipe <os.pipe>`.
-.. class:: InterpreterPoolExecutor(max_workers=None, thread_name_prefix='', initializer=None, initargs=(), shared=None)
+.. class:: InterpreterPoolExecutor(max_workers=None, thread_name_prefix='', initializer=None, initargs=())
A :class:`ThreadPoolExecutor` subclass that executes calls asynchronously
using a pool of at most *max_workers* threads. Each thread runs
@@ -305,20 +305,9 @@ the bytes over a shared :mod:`socket <socket>` or
interpreter.
.. note::
- Functions defined in the ``__main__`` module cannot be pickled
- and thus cannot be used.
-
- .. note::
The executor may replace uncaught exceptions from *initializer*
with :class:`~concurrent.futures.interpreter.ExecutionFailed`.
- The optional *shared* argument is a :class:`dict` of objects that all
- interpreters in the pool share. The *shared* items are added to each
- interpreter's ``__main__`` module. Not all objects are shareable.
- Shareable objects include the builtin singletons, :class:`str`
- and :class:`bytes`, and :class:`memoryview`. See :pep:`734`
- for more info.
-
Other caveats from parent :class:`ThreadPoolExecutor` apply here.
:meth:`~Executor.submit` and :meth:`~Executor.map` work like normal,
@@ -326,10 +315,6 @@ except the worker serializes the callable and arguments using
:mod:`pickle` when sending them to its interpreter. The worker
likewise serializes the return value when sending it back.
-.. note::
- Functions defined in the ``__main__`` module cannot be pickled
- and thus cannot be used.
-
When a worker's current task raises an uncaught exception, the worker
always tries to preserve the exception as-is. If that is successful
then it also sets the ``__cause__`` to a corresponding
diff --git a/Doc/library/ctypes.rst b/Doc/library/ctypes.rst
index 2ee4450698a..e00fe9c8145 100644
--- a/Doc/library/ctypes.rst
+++ b/Doc/library/ctypes.rst
@@ -882,7 +882,7 @@ invalid non-\ ``NULL`` pointers would crash Python)::
Thread safety without the GIL
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-In Python 3.13, the :term:`GIL` may be disabled on :term:`experimental free threaded <free threading>` builds.
+From Python 3.13 onward, the :term:`GIL` can be disabled on :term:`free threaded <free threading>` builds.
In ctypes, reads and writes to a single object concurrently is safe, but not across multiple objects:
.. code-block:: pycon
diff --git a/Doc/library/dialog.rst b/Doc/library/dialog.rst
index 191e0da1210..e0693e8eb6e 100644
--- a/Doc/library/dialog.rst
+++ b/Doc/library/dialog.rst
@@ -220,7 +220,7 @@ is the base class for dialogs defined in other supporting modules.
.. class:: Dialog(master=None, **options)
- .. method:: show(color=None, **options)
+ .. method:: show(**options)
Render the Dialog window.
diff --git a/Doc/library/dis.rst b/Doc/library/dis.rst
index 44767b5dd2d..11685a32f48 100644
--- a/Doc/library/dis.rst
+++ b/Doc/library/dis.rst
@@ -1094,14 +1094,6 @@ iterations of the loop.
.. versionadded:: 3.14
-.. opcode:: LOAD_CONST_IMMORTAL (consti)
-
- Pushes ``co_consts[consti]`` onto the stack.
- Can be used when the constant value is known to be immortal.
-
- .. versionadded:: 3.14
-
-
.. opcode:: LOAD_NAME (namei)
Pushes the value associated with ``co_names[namei]`` onto the stack.
diff --git a/Doc/library/email.header.rst b/Doc/library/email.header.rst
index 219fad0d2f6..c3392a62b8e 100644
--- a/Doc/library/email.header.rst
+++ b/Doc/library/email.header.rst
@@ -178,16 +178,36 @@ The :mod:`email.header` module also provides the following convenient functions.
Decode a message header value without converting the character set. The header
value is in *header*.
- This function returns a list of ``(decoded_string, charset)`` pairs containing
- each of the decoded parts of the header. *charset* is ``None`` for non-encoded
- parts of the header, otherwise a lower case string containing the name of the
- character set specified in the encoded string.
+ For historical reasons, this function may return either:
- Here's an example::
+ 1. A list of pairs containing each of the decoded parts of the header,
+ ``(decoded_bytes, charset)``, where *decoded_bytes* is always an instance of
+ :class:`bytes`, and *charset* is either:
+
+ - A lower case string containing the name of the character set specified.
+
+ - ``None`` for non-encoded parts of the header.
+
+ 2. A list of length 1 containing a pair ``(string, None)``, where
+ *string* is always an instance of :class:`str`.
+
+ An :exc:`email.errors.HeaderParseError` may be raised when certain decoding
+ errors occur (e.g. a base64 decoding exception).
+
+ Here are examples:
>>> from email.header import decode_header
>>> decode_header('=?iso-8859-1?q?p=F6stal?=')
[(b'p\xf6stal', 'iso-8859-1')]
+ >>> decode_header('unencoded_string')
+ [('unencoded_string', None)]
+ >>> decode_header('bar =?utf-8?B?ZsOzbw==?=')
+ [(b'bar ', None), (b'f\xc3\xb3o', 'utf-8')]
+
+ .. note::
+
+ This function exists for for backwards compatibility only. For
+ new code, we recommend using :class:`email.headerregistry.HeaderRegistry`.
.. function:: make_header(decoded_seq, maxlinelen=None, header_name=None, continuation_ws=' ')
@@ -203,3 +223,7 @@ The :mod:`email.header` module also provides the following convenient functions.
:class:`Header` instance. Optional *maxlinelen*, *header_name*, and
*continuation_ws* are as in the :class:`Header` constructor.
+ .. note::
+
+ This function exists for for backwards compatibility only, and is
+ not recommended for use in new code.
diff --git a/Doc/library/logging.config.rst b/Doc/library/logging.config.rst
index f8c71005a53..96cca3073fe 100644
--- a/Doc/library/logging.config.rst
+++ b/Doc/library/logging.config.rst
@@ -586,7 +586,7 @@ configuration dictionary for the handler named ``foo``, and later (once that
handler has been configured) it points to the configured handler instance.
Thus, ``cfg://handlers.foo`` could resolve to either a dictionary or a handler
instance. In general, it is wise to name handlers in a way such that dependent
-handlers are configured _after_ any handlers they depend on; that allows
+handlers are configured *after* any handlers they depend on; that allows
something like ``cfg://handlers.foo`` to be used in configuring a handler that
depends on handler ``foo``. If that dependent handler were named ``bar``,
problems would result, because the configuration of ``bar`` would be attempted
diff --git a/Doc/library/pkgutil.rst b/Doc/library/pkgutil.rst
index 20b8f6bcf19..47d24b6f7d0 100644
--- a/Doc/library/pkgutil.rst
+++ b/Doc/library/pkgutil.rst
@@ -69,8 +69,8 @@ support.
Yield :term:`finder` objects for the given module name.
- If fullname contains a ``'.'``, the finders will be for the package
- containing fullname, otherwise they will be all registered top level
+ If *fullname* contains a ``'.'``, the finders will be for the package
+ containing *fullname*, otherwise they will be all registered top level
finders (i.e. those on both :data:`sys.meta_path` and :data:`sys.path_hooks`).
If the named module is in a package, that package is imported as a side
diff --git a/Doc/library/shutil.rst b/Doc/library/shutil.rst
index c78dfe1aafa..e7c4c4f46bd 100644
--- a/Doc/library/shutil.rst
+++ b/Doc/library/shutil.rst
@@ -327,6 +327,10 @@ Directory and files operations
The deprecated *onerror* is similar to *onexc*, except that the third
parameter it receives is the tuple returned from :func:`sys.exc_info`.
+ .. seealso::
+ :ref:`shutil-rmtree-example` for an example of handling the removal
+ of a directory tree that contains read-only files.
+
.. audit-event:: shutil.rmtree path,dir_fd shutil.rmtree
.. versionchanged:: 3.3
diff --git a/Doc/library/sqlite3.rst b/Doc/library/sqlite3.rst
index 12761baf792..641e1f1de03 100644
--- a/Doc/library/sqlite3.rst
+++ b/Doc/library/sqlite3.rst
@@ -507,6 +507,15 @@ Module constants
Version number of the runtime SQLite library as a :class:`tuple` of
:class:`integers <int>`.
+.. data:: SQLITE_KEYWORDS
+
+ A :class:`tuple` containing all sqlite3 keywords.
+
+ This constant is only available if Python was compiled with SQLite
+ 3.24.0 or greater.
+
+ .. versionadded:: next
+
.. data:: threadsafety
Integer constant required by the DB-API 2.0, stating the level of thread
diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst
index 71f9999464a..f8f727f4a23 100644
--- a/Doc/library/sys.rst
+++ b/Doc/library/sys.rst
@@ -1933,12 +1933,21 @@ always available. Unless explicitly noted otherwise, all variables are read-only
interpreter is pre-release (alpha, beta, or release candidate) then the
local and remote interpreters must be the same exact version.
- .. audit-event:: remote_debugger_script script_path
+ .. audit-event:: sys.remote_exec pid script_path
+
+ When the code is executed in the remote process, an
+ :ref:`auditing event <auditing>` ``sys.remote_exec`` is raised with
+ the *pid* and the path to the script file.
+ This event is raised in the process that called :func:`sys.remote_exec`.
+
+ .. audit-event:: cpython.remote_debugger_script script_path
When the script is executed in the remote process, an
:ref:`auditing event <auditing>`
- ``sys.remote_debugger_script`` is raised
+ ``cpython.remote_debugger_script`` is raised
with the path in the remote process.
+ This event is raised in the remote process, not the one
+ that called :func:`sys.remote_exec`.
.. availability:: Unix, Windows.
.. versionadded:: 3.14
diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
index 7edcdcabdce..52fefd590da 100644
--- a/Doc/library/threading.rst
+++ b/Doc/library/threading.rst
@@ -102,7 +102,7 @@ CPU-bound tasks, as only one thread can execute Python bytecode at a time.
Despite this, threads remain a useful tool for achieving concurrency in many
scenarios.
-As of Python 3.13, experimental :term:`free-threaded <free threading>` builds
+As of Python 3.13, :term:`free-threaded <free threading>` builds
can disable the GIL, enabling true parallel execution of threads, but this
feature is not available by default (see :pep:`703`).
diff --git a/Doc/library/uuid.rst b/Doc/library/uuid.rst
index 92d58024e84..6698e6d3f43 100644
--- a/Doc/library/uuid.rst
+++ b/Doc/library/uuid.rst
@@ -193,43 +193,52 @@ The :mod:`uuid` module defines the following functions:
.. function:: uuid1(node=None, clock_seq=None)
- Generate a UUID from a host ID, sequence number, and the current time. If *node*
- is not given, :func:`getnode` is used to obtain the hardware address. If
- *clock_seq* is given, it is used as the sequence number; otherwise a random
- 14-bit sequence number is chosen.
+ Generate a UUID from a host ID, sequence number, and the current time
+ according to :rfc:`RFC 9562, §5.1 <9562#section-5.1>`.
+
+ When *node* is not specified, :func:`getnode` is used to obtain the hardware
+ address as a 48-bit positive integer. When a sequence number *clock_seq* is
+ not specified, a pseudo-random 14-bit positive integer is generated.
+
+ If *node* or *clock_seq* exceed their expected bit count,
+ only their least significant bits are kept.
.. function:: uuid3(namespace, name)
Generate a UUID based on the MD5 hash of a namespace identifier (which is a
UUID) and a name (which is a :class:`bytes` object or a string
- that will be encoded using UTF-8).
+ that will be encoded using UTF-8)
+ according to :rfc:`RFC 9562, §5.3 <9562#section-5.3>`.
.. function:: uuid4()
- Generate a random UUID.
+ Generate a random UUID in a cryptographically-secure method
+ according to :rfc:`RFC 9562, §5.4 <9562#section-5.4>`.
.. function:: uuid5(namespace, name)
Generate a UUID based on the SHA-1 hash of a namespace identifier (which is a
UUID) and a name (which is a :class:`bytes` object or a string
- that will be encoded using UTF-8).
+ that will be encoded using UTF-8)
+ according to :rfc:`RFC 9562, §5.5 <9562#section-5.5>`.
.. function:: uuid6(node=None, clock_seq=None)
Generate a UUID from a sequence number and the current time according to
- :rfc:`9562`.
+ :rfc:`RFC 9562, §5.6 <9562#section-5.6>`.
+
This is an alternative to :func:`uuid1` to improve database locality.
When *node* is not specified, :func:`getnode` is used to obtain the hardware
address as a 48-bit positive integer. When a sequence number *clock_seq* is
not specified, a pseudo-random 14-bit positive integer is generated.
- If *node* or *clock_seq* exceed their expected bit count, only their least
- significant bits are kept.
+ If *node* or *clock_seq* exceed their expected bit count,
+ only their least significant bits are kept.
.. versionadded:: 3.14
diff --git a/Doc/library/zoneinfo.rst b/Doc/library/zoneinfo.rst
index a57f3b8b3e8..53d8e2598ec 100644
--- a/Doc/library/zoneinfo.rst
+++ b/Doc/library/zoneinfo.rst
@@ -195,7 +195,7 @@ The ``ZoneInfo`` class
The ``ZoneInfo`` class has two alternate constructors:
-.. classmethod:: ZoneInfo.from_file(fobj, /, key=None)
+.. classmethod:: ZoneInfo.from_file(file_obj, /, key=None)
Constructs a ``ZoneInfo`` object from a file-like object returning bytes
(e.g. a file opened in binary mode or an :class:`io.BytesIO` object).
@@ -325,7 +325,7 @@ The behavior of a ``ZoneInfo`` file depends on how it was constructed:
>>> a is b
False
-3. ``ZoneInfo.from_file(fobj, /, key=None)``: When constructed from a file, the
+3. ``ZoneInfo.from_file(file_obj, /, key=None)``: When constructed from a file, the
``ZoneInfo`` object raises an exception on pickling. If an end user wants to
pickle a ``ZoneInfo`` constructed from a file, it is recommended that they
use a wrapper type or a custom serialization function: either serializing by
diff --git a/Doc/reference/datamodel.rst b/Doc/reference/datamodel.rst
index 32a2e266262..4a099e81dac 100644
--- a/Doc/reference/datamodel.rst
+++ b/Doc/reference/datamodel.rst
@@ -262,6 +262,8 @@ Booleans (:class:`bool`)
a string, the strings ``"False"`` or ``"True"`` are returned, respectively.
+.. _datamodel-float:
+
:class:`numbers.Real` (:class:`float`)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/Doc/reference/expressions.rst b/Doc/reference/expressions.rst
index 3d3bf1d9840..429b3cd1f00 100644
--- a/Doc/reference/expressions.rst
+++ b/Doc/reference/expressions.rst
@@ -134,8 +134,7 @@ Literals
Python supports string and bytes literals and various numeric literals:
.. productionlist:: python-grammar
- literal: `stringliteral` | `bytesliteral`
- : | `integer` | `floatnumber` | `imagnumber`
+ literal: `stringliteral` | `bytesliteral` | `NUMBER`
Evaluation of a literal yields an object of the given type (string, bytes,
integer, floating-point number, complex number) with the given value. The value
diff --git a/Doc/reference/lexical_analysis.rst b/Doc/reference/lexical_analysis.rst
index b22eb4db794..567c70111c2 100644
--- a/Doc/reference/lexical_analysis.rst
+++ b/Doc/reference/lexical_analysis.rst
@@ -922,11 +922,20 @@ Numeric literals
floating-point literal, hexadecimal literal
octal literal, binary literal, decimal literal, imaginary literal, complex literal
-There are three types of numeric literals: integers, floating-point numbers, and
-imaginary numbers. There are no complex literals (complex numbers can be formed
-by adding a real number and an imaginary number).
+:data:`~token.NUMBER` tokens represent numeric literals, of which there are
+three types: integers, floating-point numbers, and imaginary numbers.
-Note that numeric literals do not include a sign; a phrase like ``-1`` is
+.. grammar-snippet::
+ :group: python-grammar
+
+ NUMBER: `integer` | `floatnumber` | `imagnumber`
+
+The numeric value of a numeric literal is the same as if it were passed as a
+string to the :class:`int`, :class:`float` or :class:`complex` class
+constructor, respectively.
+Note that not all valid inputs for those constructors are also valid literals.
+
+Numeric literals do not include a sign; a phrase like ``-1`` is
actually an expression composed of the unary operator '``-``' and the literal
``1``.
@@ -940,38 +949,67 @@ actually an expression composed of the unary operator '``-``' and the literal
.. _integers:
Integer literals
-----------------
+^^^^^^^^^^^^^^^^
-Integer literals are described by the following lexical definitions:
+Integer literals denote whole numbers. For example::
-.. productionlist:: python-grammar
- integer: `decinteger` | `bininteger` | `octinteger` | `hexinteger`
- decinteger: `nonzerodigit` (["_"] `digit`)* | "0"+ (["_"] "0")*
- bininteger: "0" ("b" | "B") (["_"] `bindigit`)+
- octinteger: "0" ("o" | "O") (["_"] `octdigit`)+
- hexinteger: "0" ("x" | "X") (["_"] `hexdigit`)+
- nonzerodigit: "1"..."9"
- digit: "0"..."9"
- bindigit: "0" | "1"
- octdigit: "0"..."7"
- hexdigit: `digit` | "a"..."f" | "A"..."F"
+ 7
+ 3
+ 2147483647
There is no limit for the length of integer literals apart from what can be
-stored in available memory.
+stored in available memory::
+
+ 7922816251426433759354395033679228162514264337593543950336
+
+Underscores can be used to group digits for enhanced readability,
+and are ignored for determining the numeric value of the literal.
+For example, the following literals are equivalent::
+
+ 100_000_000_000
+ 100000000000
+ 1_00_00_00_00_000
+
+Underscores can only occur between digits.
+For example, ``_123``, ``321_``, and ``123__321`` are *not* valid literals.
-Underscores are ignored for determining the numeric value of the literal. They
-can be used to group digits for enhanced readability. One underscore can occur
-between digits, and after base specifiers like ``0x``.
+Integers can be specified in binary (base 2), octal (base 8), or hexadecimal
+(base 16) using the prefixes ``0b``, ``0o`` and ``0x``, respectively.
+Hexadecimal digits 10 through 15 are represented by letters ``A``-``F``,
+case-insensitive. For example::
-Note that leading zeros in a non-zero decimal number are not allowed. This is
-for disambiguation with C-style octal literals, which Python used before version
-3.0.
+ 0b100110111
+ 0b_1110_0101
+ 0o177
+ 0o377
+ 0xdeadbeef
+ 0xDead_Beef
-Some examples of integer literals::
+An underscore can follow the base specifier.
+For example, ``0x_1f`` is a valid literal, but ``0_x1f`` and ``0x__1f`` are
+not.
- 7 2147483647 0o177 0b100110111
- 3 79228162514264337593543950336 0o377 0xdeadbeef
- 100_000_000_000 0b_1110_0101
+Leading zeros in a non-zero decimal number are not allowed.
+For example, ``0123`` is not a valid literal.
+This is for disambiguation with C-style octal literals, which Python used
+before version 3.0.
+
+Formally, integer literals are described by the following lexical definitions:
+
+.. grammar-snippet::
+ :group: python-grammar
+
+ integer: `decinteger` | `bininteger` | `octinteger` | `hexinteger` | `zerointeger`
+ decinteger: `nonzerodigit` (["_"] `digit`)*
+ bininteger: "0" ("b" | "B") (["_"] `bindigit`)+
+ octinteger: "0" ("o" | "O") (["_"] `octdigit`)+
+ hexinteger: "0" ("x" | "X") (["_"] `hexdigit`)+
+ zerointeger: "0"+ (["_"] "0")*
+ nonzerodigit: "1"..."9"
+ digit: "0"..."9"
+ bindigit: "0" | "1"
+ octdigit: "0"..."7"
+ hexdigit: `digit` | "a"..."f" | "A"..."F"
.. versionchanged:: 3.6
Underscores are now allowed for grouping purposes in literals.
@@ -984,26 +1022,58 @@ Some examples of integer literals::
.. _floating:
Floating-point literals
------------------------
+^^^^^^^^^^^^^^^^^^^^^^^
-Floating-point literals are described by the following lexical definitions:
+Floating-point (float) literals, such as ``3.14`` or ``1.5``, denote
+:ref:`approximations of real numbers <datamodel-float>`.
-.. productionlist:: python-grammar
- floatnumber: `pointfloat` | `exponentfloat`
- pointfloat: [`digitpart`] `fraction` | `digitpart` "."
- exponentfloat: (`digitpart` | `pointfloat`) `exponent`
- digitpart: `digit` (["_"] `digit`)*
- fraction: "." `digitpart`
- exponent: ("e" | "E") ["+" | "-"] `digitpart`
+They consist of *integer* and *fraction* parts, each composed of decimal digits.
+The parts are separated by a decimal point, ``.``::
+
+ 2.71828
+ 4.0
+
+Unlike in integer literals, leading zeros are allowed in the numeric parts.
+For example, ``077.010`` is legal, and denotes the same number as ``77.10``.
+
+As in integer literals, single underscores may occur between digits to help
+readability::
+
+ 96_485.332_123
+ 3.14_15_93
-Note that the integer and exponent parts are always interpreted using radix 10.
-For example, ``077e010`` is legal, and denotes the same number as ``77e10``. The
-allowed range of floating-point literals is implementation-dependent. As in
-integer literals, underscores are supported for digit grouping.
+Either of these parts, but not both, can be empty. For example::
-Some examples of floating-point literals::
+ 10. # (equivalent to 10.0)
+ .001 # (equivalent to 0.001)
- 3.14 10. .001 1e100 3.14e-10 0e0 3.14_15_93
+Optionally, the integer and fraction may be followed by an *exponent*:
+the letter ``e`` or ``E``, followed by an optional sign, ``+`` or ``-``,
+and a number in the same format as the integer and fraction parts.
+The ``e`` or ``E`` represents "times ten raised to the power of"::
+
+ 1.0e3 # (represents 1.0×10³, or 1000.0)
+ 1.166e-5 # (represents 1.166×10⁻⁵, or 0.00001166)
+ 6.02214076e+23 # (represents 6.02214076×10²³, or 602214076000000000000000.)
+
+In floats with only integer and exponent parts, the decimal point may be
+omitted::
+
+ 1e3 # (equivalent to 1.e3 and 1.0e3)
+ 0e0 # (equivalent to 0.)
+
+Formally, floating-point literals are described by the following
+lexical definitions:
+
+.. grammar-snippet::
+ :group: python-grammar
+
+ floatnumber:
+ | `digitpart` "." [`digitpart`] [`exponent`]
+ | "." `digitpart` [`exponent`]
+ | `digitpart` `exponent`
+ digitpart: `digit` (["_"] `digit`)*
+ exponent: ("e" | "E") ["+" | "-"] `digitpart`
.. versionchanged:: 3.6
Underscores are now allowed for grouping purposes in literals.
@@ -1014,20 +1084,62 @@ Some examples of floating-point literals::
.. _imaginary:
Imaginary literals
-------------------
+^^^^^^^^^^^^^^^^^^
-Imaginary literals are described by the following lexical definitions:
+Python has :ref:`complex number <typesnumeric>` objects, but no complex
+literals.
+Instead, *imaginary literals* denote complex numbers with a zero
+real part.
-.. productionlist:: python-grammar
- imagnumber: (`floatnumber` | `digitpart`) ("j" | "J")
+For example, in math, the complex number 3+4.2\ *i* is written
+as the real number 3 added to the imaginary number 4.2\ *i*.
+Python uses a similar syntax, except the imaginary unit is written as ``j``
+rather than *i*::
+
+ 3+4.2j
+
+This is an expression composed
+of the :ref:`integer literal <integers>` ``3``,
+the :ref:`operator <operators>` '``+``',
+and the :ref:`imaginary literal <imaginary>` ``4.2j``.
+Since these are three separate tokens, whitespace is allowed between them::
-An imaginary literal yields a complex number with a real part of 0.0. Complex
-numbers are represented as a pair of floating-point numbers and have the same
-restrictions on their range. To create a complex number with a nonzero real
-part, add a floating-point number to it, e.g., ``(3+4j)``. Some examples of
-imaginary literals::
+ 3 + 4.2j
- 3.14j 10.j 10j .001j 1e100j 3.14e-10j 3.14_15_93j
+No whitespace is allowed *within* each token.
+In particular, the ``j`` suffix, may not be separated from the number
+before it.
+
+The number before the ``j`` has the same syntax as a floating-point literal.
+Thus, the following are valid imaginary literals::
+
+ 4.2j
+ 3.14j
+ 10.j
+ .001j
+ 1e100j
+ 3.14e-10j
+ 3.14_15_93j
+
+Unlike in a floating-point literal the decimal point can be omitted if the
+imaginary number only has an integer part.
+The number is still evaluated as a floating-point number, not an integer::
+
+ 10j
+ 0j
+ 1000000000000000000000000j # equivalent to 1e+24j
+
+The ``j`` suffix is case-insensitive.
+That means you can use ``J`` instead::
+
+ 3.14J # equivalent to 3.14j
+
+Formally, imaginary literals are described by the following lexical definition:
+
+.. grammar-snippet::
+ :group: python-grammar
+
+ imagnumber: (`floatnumber` | `digitpart`) ("j" | "J")
.. _operators:
diff --git a/Doc/using/configure.rst b/Doc/using/configure.rst
index 0b7eaf35a1e..df81a330549 100644
--- a/Doc/using/configure.rst
+++ b/Doc/using/configure.rst
@@ -290,8 +290,8 @@ General Options
.. option:: --disable-gil
- Enables **experimental** support for running Python without the
- :term:`global interpreter lock` (GIL): free threading build.
+ Enables support for running Python without the :term:`global interpreter
+ lock` (GIL): free threading build.
Defines the ``Py_GIL_DISABLED`` macro and adds ``"t"`` to
:data:`sys.abiflags`.
diff --git a/Doc/using/mac.rst b/Doc/using/mac.rst
index 4b6c884f3d4..f88f3c2e078 100644
--- a/Doc/using/mac.rst
+++ b/Doc/using/mac.rst
@@ -20,13 +20,6 @@ the Pythons provided by the CPython release team for download from
the `python.org website <https://www.python.org/downloads/>`_. See
:ref:`alternative_bundles` for some other options.
-.. |usemac_x_dot_y| replace:: 3.13
-.. |usemac_python_x_dot_y_literal| replace:: ``python3.13``
-.. |usemac_python_x_dot_y_t_literal| replace:: ``python3.13t``
-.. |usemac_python_x_dot_y_t_literal_config| replace:: ``python3.13t-config``
-.. |usemac_applications_folder_name| replace:: ``Python 3.13``
-.. |usemac_applications_folder_version| replace:: ``/Applications/Python 3.13/``
-
.. _getting-osx:
.. _getting-and-installing-macpython:
@@ -64,7 +57,7 @@ Clicking on the **Continue** button brings up the **Read Me** for this installer
Besides other important information, the **Read Me** documents which Python version is
going to be installed and on what versions of macOS it is supported. You may need
to scroll through to read the whole file. By default, this **Read Me** will also be
-installed in |usemac_applications_folder_version| and available to read anytime.
+installed in |applications_python_version_literal| and available to read anytime.
.. image:: mac_installer_02_readme.png
@@ -83,7 +76,7 @@ display. For most uses, the standard set of installation operations is appropria
By pressing the **Customize** button, you can choose to omit or select certain package
components of the installer. Click on each package name to see a description of
what it installs.
-To also install support for the optional experimental free-threaded feature,
+To also install support for the optional free-threaded feature,
see :ref:`install-freethreaded-macos`.
.. image:: mac_installer_05_custom_install.png
@@ -97,7 +90,7 @@ When the installation is complete, the **Summary** window will appear.
.. image:: mac_installer_06_summary.png
Double-click on the :command:`Install Certificates.command`
-icon or file in the |usemac_applications_folder_version| window to complete the
+icon or file in the |applications_python_version_literal| window to complete the
installation.
.. image:: mac_installer_07_applications.png
@@ -114,7 +107,7 @@ Close this terminal window and the installer window.
A default install will include:
-* A |usemac_applications_folder_name| folder in your :file:`Applications` folder. In here
+* A |python_version_literal| folder in your :file:`Applications` folder. In here
you find :program:`IDLE`, the development environment that is a standard part of official
Python distributions; and :program:`Python Launcher`, which handles double-clicking Python
scripts from the macOS `Finder <https://support.apple.com/en-us/HT201732>`_.
@@ -141,7 +134,7 @@ How to run a Python script
There are two ways to invoke the Python interpreter.
If you are familiar with using a Unix shell in a terminal
-window, you can invoke |usemac_python_x_dot_y_literal| or ``python3`` optionally
+window, you can invoke |python_x_dot_y_literal| or ``python3`` optionally
followed by one or more command line options (described in :ref:`using-on-general`).
The Python tutorial also has a useful section on
:ref:`using Python interactively from a shell <tut-interac>`.
@@ -160,7 +153,7 @@ for more information.
To run a Python script file from the terminal window, you can
invoke the interpreter with the name of the script file:
- |usemac_python_x_dot_y_literal| ``myscript.py``
+ |python_x_dot_y_literal| ``myscript.py``
To run your script from the Finder, you can either:
@@ -259,20 +252,20 @@ Advanced Topics
Installing Free-threaded Binaries
---------------------------------
-.. versionadded:: 3.13 (Experimental)
-
-.. note::
-
- Everything described in this section is considered experimental,
- and should be expected to change in future releases.
+.. versionadded:: 3.13
The ``python.org`` :ref:`Python for macOS <getting-and-installing-macpython>`
installer package can optionally install an additional build of
-Python |usemac_x_dot_y| that supports :pep:`703`, the experimental free-threading feature
+Python |version| that supports :pep:`703`, the free-threading feature
(running with the :term:`global interpreter lock` disabled).
Check the release page on ``python.org`` for possible updated information.
-Because this feature is still considered experimental, the support for it
+The free-threaded mode is working and continues to be improved, but
+there is some additional overhead in single-threaded workloads compared
+to the regular build. Additionally, third-party packages, in particular ones
+with an :term:`extension module`, may not be ready for use in a
+free-threaded build, and will re-enable the :term:`GIL`.
+Therefore, the support for free-threading
is not installed by default. It is packaged as a separate install option,
available by clicking the **Customize** button on the **Installation Type**
step of the installer as described above.
@@ -282,46 +275,54 @@ step of the installer as described above.
If the box next to the **Free-threaded Python** package name is checked,
a separate :file:`PythonT.framework` will also be installed
alongside the normal :file:`Python.framework` in :file:`/Library/Frameworks`.
-This configuration allows a free-threaded Python |usemac_x_dot_y| build to co-exist
-on your system with a traditional (GIL only) Python |usemac_x_dot_y| build with
-minimal risk while installing or testing. This installation layout is itself
-experimental and is subject to change in future releases.
+This configuration allows a free-threaded Python |version| build to co-exist
+on your system with a traditional (GIL only) Python |version| build with
+minimal risk while installing or testing. This installation layout may
+change in future releases.
Known cautions and limitations:
- The **UNIX command-line tools** package, which is selected by default,
- will install links in :file:`/usr/local/bin` for |usemac_python_x_dot_y_t_literal|,
- the free-threaded interpreter, and |usemac_python_x_dot_y_t_literal_config|,
+ will install links in :file:`/usr/local/bin` for |python_x_dot_y_t_literal|,
+ the free-threaded interpreter, and |python_x_dot_y_t_literal_config|,
a configuration utility which may be useful for package builders.
Since :file:`/usr/local/bin` is typically included in your shell ``PATH``,
in most cases no changes to your ``PATH`` environment variables should
- be needed to use |usemac_python_x_dot_y_t_literal|.
+ be needed to use |python_x_dot_y_t_literal|.
- For this release, the **Shell profile updater** package and the
- :file:`Update Shell Profile.command` in |usemac_applications_folder_version|
+ :file:`Update Shell Profile.command` in |applications_python_version_literal|
do not support the free-threaded package.
- The free-threaded build and the traditional build have separate search
paths and separate :file:`site-packages` directories so, by default,
if you need a package available in both builds, it may need to be installed in both.
The free-threaded package will install a separate instance of :program:`pip` for use
- with |usemac_python_x_dot_y_t_literal|.
+ with |python_x_dot_y_t_literal|.
- To install a package using :command:`pip` without a :command:`venv`:
- |usemac_python_x_dot_y_t_literal| ``-m pip install <package_name>``
+ .. parsed-literal::
+
+ python\ |version|\ t -m pip install <package_name>
- When working with multiple Python environments, it is usually safest and easiest
to :ref:`create and use virtual environments <tut-venv>`.
This can avoid possible command name conflicts and confusion about which Python is in use:
- |usemac_python_x_dot_y_t_literal| ``-m venv <venv_name>``
+ .. parsed-literal::
+
+ python\ |version|\ t -m venv <venv_name>
+
then :command:`activate`.
- To run a free-threaded version of IDLE:
- |usemac_python_x_dot_y_t_literal| ``-m idlelib``
+ .. parsed-literal::
+
+ python\ |version|\ t -m idlelib
+
- The interpreters in both builds respond to the same
:ref:`PYTHON environment variables <using-on-envvars>`
@@ -337,28 +338,28 @@ Known cautions and limitations:
thus it only needs to be run once.
- If you cannot depend on the link in ``/usr/local/bin`` pointing to the
- ``python.org`` free-threaded |usemac_python_x_dot_y_t_literal| (for example, if you want
+ ``python.org`` free-threaded |python_x_dot_y_t_literal| (for example, if you want
to install your own version there or some other distribution does),
you can explicitly set your shell ``PATH`` environment variable to
include the ``PythonT`` framework ``bin`` directory:
- .. code-block:: sh
+ .. parsed-literal::
- export PATH="/Library/Frameworks/PythonT.framework/Versions/3.13/bin":"$PATH"
+ export PATH="/Library/Frameworks/PythonT.framework/Versions/\ |version|\ /bin":"$PATH"
The traditional framework installation by default does something similar,
except for :file:`Python.framework`. Be aware that having both framework ``bin``
directories in ``PATH`` can lead to confusion if there are duplicate names
- like ``python3.13`` in both; which one is actually used depends on the order
+ like |python_x_dot_y_literal| in both; which one is actually used depends on the order
they appear in ``PATH``. The ``which python3.x`` or ``which python3.xt``
commands can show which path is being used. Using virtual environments
can help avoid such ambiguities. Another option might be to create
a shell :command:`alias` to the desired interpreter, like:
- .. code-block:: sh
+ .. parsed-literal::
- alias py3.13="/Library/Frameworks/Python.framework/Versions/3.13/bin/python3.13"
- alias py3.13t="/Library/Frameworks/PythonT.framework/Versions/3.13/bin/python3.13t"
+ alias py\ |version|\ ="/Library/Frameworks/Python.framework/Versions/\ |version|\ /bin/python\ |version|\ "
+ alias py\ |version|\ t="/Library/Frameworks/PythonT.framework/Versions/\ |version|\ /bin/python\ |version|\ t"
Installing using the command line
---------------------------------
@@ -369,22 +370,22 @@ the macOS command line :command:`installer` utility lets you select non-default
options, too. If you are not familiar with :command:`installer`, it can be
somewhat cryptic (see :command:`man installer` for more information).
As an example, the following shell snippet shows one way to do it,
-using the ``3.13.0b2`` release and selecting the free-threaded interpreter
+using the |x_dot_y_b2_literal| release and selecting the free-threaded interpreter
option:
-.. code-block:: sh
+.. parsed-literal::
- RELEASE="python-3.13.0b2-macos11.pkg"
+ RELEASE="python-\ |version|\ 0b2-macos11.pkg"
# download installer pkg
- curl -O https://www.python.org/ftp/python/3.13.0/${RELEASE}
+ curl -O \https://www.python.org/ftp/python/\ |version|\ .0/${RELEASE}
# create installer choicechanges to customize the install:
- # enable the PythonTFramework-3.13 package
+ # enable the PythonTFramework-\ |version|\ package
# while accepting the other defaults (install all other packages)
cat > ./choicechanges.plist <<EOF
<?xml version="1.0" encoding="UTF-8"?>
- <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+ <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "\http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
<dict>
@@ -393,7 +394,7 @@ option:
<key>choiceAttribute</key>
<string>selected</string>
<key>choiceIdentifier</key>
- <string>org.python.Python.PythonTFramework-3.13</string>
+ <string>org.python.Python.PythonTFramework-\ |version|\ </string>
</dict>
</array>
</plist>
@@ -404,19 +405,19 @@ option:
You can then test that both installer builds are now available with something like:
-.. code-block:: console
+.. parsed-literal::
$ # test that the free-threaded interpreter was installed if the Unix Command Tools package was enabled
- $ /usr/local/bin/python3.13t -VV
- Python 3.13.0b2 experimental free-threading build (v3.13.0b2:3a83b172af, Jun 5 2024, 12:57:31) [Clang 15.0.0 (clang-1500.3.9.4)]
+ $ /usr/local/bin/python\ |version|\ t -VV
+ Python \ |version|\ .0b2 free-threading build (v\ |version|\ .0b2:3a83b172af, Jun 5 2024, 12:57:31) [Clang 15.0.0 (clang-1500.3.9.4)]
$ # and the traditional interpreter
- $ /usr/local/bin/python3.13 -VV
- Python 3.13.0b2 (v3.13.0b2:3a83b172af, Jun 5 2024, 12:50:24) [Clang 15.0.0 (clang-1500.3.9.4)]
+ $ /usr/local/bin/python\ |version|\ -VV
+ Python \ |version|\ .0b2 (v\ |version|\ .0b2:3a83b172af, Jun 5 2024, 12:50:24) [Clang 15.0.0 (clang-1500.3.9.4)]
$ # test that they are also available without the prefix if /usr/local/bin is on $PATH
- $ python3.13t -VV
- Python 3.13.0b2 experimental free-threading build (v3.13.0b2:3a83b172af, Jun 5 2024, 12:57:31) [Clang 15.0.0 (clang-1500.3.9.4)]
- $ python3.13 -VV
- Python 3.13.0b2 (v3.13.0b2:3a83b172af, Jun 5 2024, 12:50:24) [Clang 15.0.0 (clang-1500.3.9.4)]
+ $ python\ |version|\ t -VV
+ Python \ |version|\ .0b2 free-threading build (v\ |version|\ .0b2:3a83b172af, Jun 5 2024, 12:57:31) [Clang 15.0.0 (clang-1500.3.9.4)]
+ $ python\ |version|\ -VV
+ Python \ |version|\ .0b2 (v\ |version|\ .0b2:3a83b172af, Jun 5 2024, 12:50:24) [Clang 15.0.0 (clang-1500.3.9.4)]
.. note::
diff --git a/Doc/whatsnew/3.14.rst b/Doc/whatsnew/3.14.rst
index 895446e2721..f0a87a9ada7 100644
--- a/Doc/whatsnew/3.14.rst
+++ b/Doc/whatsnew/3.14.rst
@@ -82,9 +82,10 @@ and improvements in user-friendliness and correctness.
.. PEP-sized items next.
+* :ref:`PEP 779: Free-threaded Python is officially supported <whatsnew314-pep779>`
* :ref:`PEP 649 and 749: deferred evaluation of annotations <whatsnew314-pep649>`
-* :ref:`PEP 734: Multiple Interpreters in the Stdlib <whatsnew314-pep734>`
-* :ref:`PEP 741: Python Configuration C API <whatsnew314-pep741>`
+* :ref:`PEP 734: Multiple interpreters in the stdlib <whatsnew314-pep734>`
+* :ref:`PEP 741: Python configuration C API <whatsnew314-pep741>`
* :ref:`PEP 750: Template strings <whatsnew314-pep750>`
* :ref:`PEP 758: Allow except and except* expressions without parentheses <whatsnew314-pep758>`
* :ref:`PEP 761: Discontinuation of PGP signatures <whatsnew314-pep761>`
@@ -124,9 +125,35 @@ of Python. See :ref:`below <whatsnew314-refcount>` for details.
New features
============
+.. _whatsnew314-pep779:
+
+PEP 779: Free-threaded Python is officially supported
+-----------------------------------------------------
+
+The free-threaded build of Python is now supported and no longer experimental.
+This is the start of phase II where free-threaded Python is officially supported
+but still optional.
+
+We are confident that the project is on the right path, and we appreciate the
+continued dedication from everyone working to make free-threading ready for
+broader adoption across the Python community.
+
+With these recommendations and the acceptance of this PEP, we as the Python
+developer community should broadly advertise that free-threading is a supported
+Python build option now and into the future, and that it will not be removed
+without a proper deprecation schedule.
+
+Any decision to transition to phase III, with free-threading as the default or
+sole build of Python is still undecided, and dependent on many factors both
+within CPython itself and the community. This decision is for the future.
+
+.. seealso::
+ :pep:`779` and its `acceptance
+ <https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319/123>`__.
+
.. _whatsnew314-pep734:
-PEP 734: Multiple Interpreters in the Stdlib
+PEP 734: Multiple interpreters in the stdlib
--------------------------------------------
The CPython runtime supports running multiple copies of Python in the
@@ -392,7 +419,7 @@ As can be seen, the API is similar to the APIs of the :mod:`!lzma` and
:mod:`!bz2` modules.
(Contributed by Emma Harper Smith, Adam Turner, Gregory P. Smith, Tomas Roun,
-Victor Stinner, and Rogdham in :gh:`132983`)
+Victor Stinner, and Rogdham in :gh:`132983`.)
.. seealso::
:pep:`784`.
@@ -727,7 +754,7 @@ Improved error messages
.. _whatsnew314-pep741:
-PEP 741: Python Configuration C API
+PEP 741: Python configuration C API
-----------------------------------
Add a :ref:`PyInitConfig C API <pyinitconfig_api>` to configure the Python
@@ -1266,7 +1293,7 @@ configparser
to :meth:`configparser.ConfigParser.write` keys containing delimiters or
beginning with the section header pattern will raise a
:class:`configparser.InvalidWriteError`.
- (Contributed by Jacob Lincoln in :gh:`129270`)
+ (Contributed by Jacob Lincoln in :gh:`129270`.)
contextvars
-----------
@@ -2755,8 +2782,8 @@ New features
* Add :c:func:`PyType_GetBaseByToken` and :c:data:`Py_tp_token` slot for easier
superclass identification, which attempts to resolve the `type checking issue
- <https://peps.python.org/pep-0630/#type-checking>`__ mentioned in :pep:`630`
- (:gh:`124153`).
+ <https://peps.python.org/pep-0630/#type-checking>`__ mentioned in :pep:`630`.
+ (Contributed in :gh:`124153`.)
* Add :c:func:`PyUnicode_Equal` function to the limited C API:
test if two strings are equal.