mirror of
https://github.com/python/cpython.git
synced 2025-12-08 06:10:17 +00:00
Python 3.14.1
This commit is contained in:
Hugo van Kemenade
parent
49fe7574d9
commit
be35a63d71
209 changed files with 2451 additions and 548 deletions
|
|
@ -1555,7 +1555,7 @@ All of the following functions must be called after :c:func:`Py_Initialize`.
|
|||
|
||||
See :c:func:`PyUnstable_ThreadState_ResetStackProtection` for undoing this operation.
|
||||
|
||||
.. versionadded:: next
|
||||
.. versionadded:: 3.14.1
|
||||
|
||||
.. warning::
|
||||
|
||||
|
|
@ -1575,7 +1575,7 @@ All of the following functions must be called after :c:func:`Py_Initialize`.
|
|||
|
||||
See :c:func:`PyUnstable_ThreadState_SetStackProtection` for an explanation.
|
||||
|
||||
.. versionadded:: next
|
||||
.. versionadded:: 3.14.1
|
||||
|
||||
.. warning::
|
||||
|
||||
|
|
|
|||
|
|
@ -254,7 +254,7 @@ common XML vulnerabilities.
|
|||
The corresponding :attr:`~ExpatError.lineno` and :attr:`~ExpatError.offset`
|
||||
should not be used as they may have no special meaning.
|
||||
|
||||
.. versionadded:: next
|
||||
.. versionadded:: 3.14.1
|
||||
|
||||
.. method:: xmlparser.SetAllocTrackerMaximumAmplification(max_factor, /)
|
||||
|
||||
|
|
@ -284,7 +284,7 @@ common XML vulnerabilities.
|
|||
that can be adjusted by :meth:`.SetAllocTrackerActivationThreshold`
|
||||
is exceeded.
|
||||
|
||||
.. versionadded:: next
|
||||
.. versionadded:: 3.14.1
|
||||
|
||||
|
||||
:class:`xmlparser` objects have the following attributes:
|
||||
|
|
|
|||
|
|
@ -1614,7 +1614,7 @@ Cursor objects
|
|||
If the *size* parameter is used, then it is best for it to retain the same
|
||||
value from one :meth:`fetchmany` call to the next.
|
||||
|
||||
.. versionchanged:: next
|
||||
.. versionchanged:: 3.14.1
|
||||
Negative *size* values are rejected by raising :exc:`ValueError`.
|
||||
|
||||
.. method:: fetchall()
|
||||
|
|
@ -1644,7 +1644,7 @@ Cursor objects
|
|||
Read/write attribute that controls the number of rows returned by :meth:`fetchmany`.
|
||||
The default value is 1 which means a single row would be fetched per call.
|
||||
|
||||
.. versionchanged:: next
|
||||
.. versionchanged:: 3.14.1
|
||||
Negative values are rejected by raising :exc:`ValueError`.
|
||||
|
||||
.. attribute:: connection
|
||||
|
|
|
|||
|
|
@ -19,12 +19,12 @@
|
|||
/*--start constants--*/
|
||||
#define PY_MAJOR_VERSION 3
|
||||
#define PY_MINOR_VERSION 14
|
||||
#define PY_MICRO_VERSION 0
|
||||
#define PY_MICRO_VERSION 1
|
||||
#define PY_RELEASE_LEVEL PY_RELEASE_LEVEL_FINAL
|
||||
#define PY_RELEASE_SERIAL 0
|
||||
|
||||
/* Version as a string */
|
||||
#define PY_VERSION "3.14.0+"
|
||||
#define PY_VERSION "3.14.1"
|
||||
/*--end constants--*/
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Autogenerated by Sphinx on Tue Oct 7 12:34:44 2025
|
||||
# Autogenerated by Sphinx on Tue Dec 2 14:51:32 2025
|
||||
# as part of the release process.
|
||||
|
||||
topics = {
|
||||
|
|
@ -1098,10 +1098,10 @@ class and instance attributes applies as for regular assignments.
|
|||
'bltin-ellipsis-object': r'''The Ellipsis Object
|
||||
*******************
|
||||
|
||||
This object is commonly used used to indicate that something is
|
||||
omitted. It supports no special operations. There is exactly one
|
||||
ellipsis object, named "Ellipsis" (a built-in name).
|
||||
"type(Ellipsis)()" produces the "Ellipsis" singleton.
|
||||
This object is commonly used to indicate that something is omitted. It
|
||||
supports no special operations. There is exactly one ellipsis object,
|
||||
named "Ellipsis" (a built-in name). "type(Ellipsis)()" produces the
|
||||
"Ellipsis" singleton.
|
||||
|
||||
It is written as "Ellipsis" or "...".
|
||||
|
||||
|
|
@ -1946,15 +1946,29 @@ class attributes; they are shared by instances. Instance attributes
|
|||
"except*" clause
|
||||
----------------
|
||||
|
||||
The "except*" clause(s) are used for handling "ExceptionGroup"s. The
|
||||
exception type for matching is interpreted as in the case of "except",
|
||||
but in the case of exception groups we can have partial matches when
|
||||
the type matches some of the exceptions in the group. This means that
|
||||
multiple "except*" clauses can execute, each handling part of the
|
||||
exception group. Each clause executes at most once and handles an
|
||||
exception group of all matching exceptions. Each exception in the
|
||||
group is handled by at most one "except*" clause, the first that
|
||||
matches it.
|
||||
The "except*" clause(s) specify one or more handlers for groups of
|
||||
exceptions ("BaseExceptionGroup" instances). A "try" statement can
|
||||
have either "except" or "except*" clauses, but not both. The exception
|
||||
type for matching is mandatory in the case of "except*", so "except*:"
|
||||
is a syntax error. The type is interpreted as in the case of "except",
|
||||
but matching is performed on the exceptions contained in the group
|
||||
that is being handled. An "TypeError" is raised if a matching type is
|
||||
a subclass of "BaseExceptionGroup", because that would have ambiguous
|
||||
semantics.
|
||||
|
||||
When an exception group is raised in the try block, each "except*"
|
||||
clause splits (see "split()") it into the subgroups of matching and
|
||||
non-matching exceptions. If the matching subgroup is not empty, it
|
||||
becomes the handled exception (the value returned from
|
||||
"sys.exception()") and assigned to the target of the "except*" clause
|
||||
(if there is one). Then, the body of the "except*" clause executes. If
|
||||
the non-matching subgroup is not empty, it is processed by the next
|
||||
"except*" in the same manner. This continues until all exceptions in
|
||||
the group have been matched, or the last "except*" clause has run.
|
||||
|
||||
After all "except*" clauses execute, the group of unhandled exceptions
|
||||
is merged with any exceptions that were raised or re-raised from
|
||||
within "except*" clauses. This merged exception group propagates on.:
|
||||
|
||||
>>> try:
|
||||
... raise ExceptionGroup("eg",
|
||||
|
|
@ -1967,20 +1981,19 @@ class attributes; they are shared by instances. Instance attributes
|
|||
caught <class 'ExceptionGroup'> with nested (TypeError(2),)
|
||||
caught <class 'ExceptionGroup'> with nested (OSError(3), OSError(4))
|
||||
+ Exception Group Traceback (most recent call last):
|
||||
| File "<stdin>", line 2, in <module>
|
||||
| ExceptionGroup: eg
|
||||
| File "<doctest default[0]>", line 2, in <module>
|
||||
| raise ExceptionGroup("eg",
|
||||
| [ValueError(1), TypeError(2), OSError(3), OSError(4)])
|
||||
| ExceptionGroup: eg (1 sub-exception)
|
||||
+-+---------------- 1 ----------------
|
||||
| ValueError: 1
|
||||
+------------------------------------
|
||||
|
||||
Any remaining exceptions that were not handled by any "except*" clause
|
||||
are re-raised at the end, along with all exceptions that were raised
|
||||
from within the "except*" clauses. If this list contains more than one
|
||||
exception to reraise, they are combined into an exception group.
|
||||
|
||||
If the raised exception is not an exception group and its type matches
|
||||
one of the "except*" clauses, it is caught and wrapped by an exception
|
||||
group with an empty message string.
|
||||
If the exception raised from the "try" block is not an exception group
|
||||
and its type matches one of the "except*" clauses, it is caught and
|
||||
wrapped by an exception group with an empty message string. This
|
||||
ensures that the type of the target "e" is consistently
|
||||
"BaseExceptionGroup":
|
||||
|
||||
>>> try:
|
||||
... raise BlockingIOError
|
||||
|
|
@ -1989,13 +2002,7 @@ class attributes; they are shared by instances. Instance attributes
|
|||
...
|
||||
ExceptionGroup('', (BlockingIOError()))
|
||||
|
||||
An "except*" clause must have a matching expression; it cannot be
|
||||
"except*:". Furthermore, this expression cannot contain exception
|
||||
group types, because that would have ambiguous semantics.
|
||||
|
||||
It is not possible to mix "except" and "except*" in the same "try".
|
||||
The "break", "continue", and "return" statements cannot appear in an
|
||||
"except*" clause.
|
||||
"break", "continue" and "return" cannot appear in an "except*" clause.
|
||||
|
||||
|
||||
"else" clause
|
||||
|
|
@ -2665,7 +2672,7 @@ def foo():
|
|||
If only keyword patterns are present, they are processed as
|
||||
follows, one by one:
|
||||
|
||||
I. The keyword is looked up as an attribute on the subject.
|
||||
1. The keyword is looked up as an attribute on the subject.
|
||||
|
||||
* If this raises an exception other than "AttributeError", the
|
||||
exception bubbles up.
|
||||
|
|
@ -2677,14 +2684,14 @@ def foo():
|
|||
the class pattern fails; if this succeeds, the match proceeds
|
||||
to the next keyword.
|
||||
|
||||
II. If all keyword patterns succeed, the class pattern succeeds.
|
||||
2. If all keyword patterns succeed, the class pattern succeeds.
|
||||
|
||||
If any positional patterns are present, they are converted to
|
||||
keyword patterns using the "__match_args__" attribute on the class
|
||||
"name_or_attr" before matching:
|
||||
|
||||
I. The equivalent of "getattr(cls, "__match_args__", ())" is
|
||||
called.
|
||||
1. The equivalent of "getattr(cls, "__match_args__", ())" is
|
||||
called.
|
||||
|
||||
* If this raises an exception, the exception bubbles up.
|
||||
|
||||
|
|
@ -2705,9 +2712,9 @@ def foo():
|
|||
|
||||
Customizing positional arguments in class pattern matching
|
||||
|
||||
II. Once all positional patterns have been converted to keyword
|
||||
patterns,
|
||||
the match proceeds as if there were only keyword patterns.
|
||||
2. Once all positional patterns have been converted to keyword
|
||||
patterns, the match proceeds as if there were only keyword
|
||||
patterns.
|
||||
|
||||
For the following built-in types the handling of positional
|
||||
subpatterns is different:
|
||||
|
|
@ -3909,6 +3916,10 @@ def double(x):
|
|||
available for commands and command arguments, e.g. the current global
|
||||
and local names are offered as arguments of the "p" command.
|
||||
|
||||
|
||||
Command-line interface
|
||||
======================
|
||||
|
||||
You can also invoke "pdb" from the command line to debug other
|
||||
scripts. For example:
|
||||
|
||||
|
|
@ -3924,7 +3935,7 @@ def double(x):
|
|||
-c, --command <command>
|
||||
|
||||
To execute commands as if given in a ".pdbrc" file; see Debugger
|
||||
Commands.
|
||||
commands.
|
||||
|
||||
Changed in version 3.2: Added the "-c" option.
|
||||
|
||||
|
|
@ -4145,7 +4156,7 @@ class pdb.Pdb(completekey='tab', stdin=None, stdout=None, skip=None, nosigint=Fa
|
|||
See the documentation for the functions explained above.
|
||||
|
||||
|
||||
Debugger Commands
|
||||
Debugger commands
|
||||
=================
|
||||
|
||||
The commands recognized by the debugger are listed below. Most
|
||||
|
|
@ -4808,11 +4819,6 @@ class of the instance or a *non-virtual base class* thereof. The
|
|||
|
||||
See also the description of the "try" statement in section The try
|
||||
statement and "raise" statement in section The raise statement.
|
||||
|
||||
-[ Footnotes ]-
|
||||
|
||||
[1] This limitation occurs because the code that is executed by these
|
||||
operations is not available at the time the module is compiled.
|
||||
''',
|
||||
'execmodel': r'''Execution model
|
||||
***************
|
||||
|
|
@ -5166,6 +5172,181 @@ class of the instance or a *non-virtual base class* thereof. The
|
|||
See also the description of the "try" statement in section The try
|
||||
statement and "raise" statement in section The raise statement.
|
||||
|
||||
|
||||
Runtime Components
|
||||
==================
|
||||
|
||||
|
||||
General Computing Model
|
||||
-----------------------
|
||||
|
||||
Python’s execution model does not operate in a vacuum. It runs on a
|
||||
host machine and through that host’s runtime environment, including
|
||||
its operating system (OS), if there is one. When a program runs, the
|
||||
conceptual layers of how it runs on the host look something like this:
|
||||
|
||||
**host machine**
|
||||
**process** (global resources)
|
||||
**thread** (runs machine code)
|
||||
|
||||
Each process represents a program running on the host. Think of each
|
||||
process itself as the data part of its program. Think of the process’
|
||||
threads as the execution part of the program. This distinction will
|
||||
be important to understand the conceptual Python runtime.
|
||||
|
||||
The process, as the data part, is the execution context in which the
|
||||
program runs. It mostly consists of the set of resources assigned to
|
||||
the program by the host, including memory, signals, file handles,
|
||||
sockets, and environment variables.
|
||||
|
||||
Processes are isolated and independent from one another. (The same is
|
||||
true for hosts.) The host manages the process’ access to its assigned
|
||||
resources, in addition to coordinating between processes.
|
||||
|
||||
Each thread represents the actual execution of the program’s machine
|
||||
code, running relative to the resources assigned to the program’s
|
||||
process. It’s strictly up to the host how and when that execution
|
||||
takes place.
|
||||
|
||||
From the point of view of Python, a program always starts with exactly
|
||||
one thread. However, the program may grow to run in multiple
|
||||
simultaneous threads. Not all hosts support multiple threads per
|
||||
process, but most do. Unlike processes, threads in a process are not
|
||||
isolated and independent from one another. Specifically, all threads
|
||||
in a process share all of the process’ resources.
|
||||
|
||||
The fundamental point of threads is that each one does *run*
|
||||
independently, at the same time as the others. That may be only
|
||||
conceptually at the same time (“concurrently”) or physically (“in
|
||||
parallel”). Either way, the threads effectively run at a non-
|
||||
synchronized rate.
|
||||
|
||||
Note:
|
||||
|
||||
That non-synchronized rate means none of the process’ memory is
|
||||
guaranteed to stay consistent for the code running in any given
|
||||
thread. Thus multi-threaded programs must take care to coordinate
|
||||
access to intentionally shared resources. Likewise, they must take
|
||||
care to be absolutely diligent about not accessing any *other*
|
||||
resources in multiple threads; otherwise two threads running at the
|
||||
same time might accidentally interfere with each other’s use of some
|
||||
shared data. All this is true for both Python programs and the
|
||||
Python runtime.The cost of this broad, unstructured requirement is
|
||||
the tradeoff for the kind of raw concurrency that threads provide.
|
||||
The alternative to the required discipline generally means dealing
|
||||
with non-deterministic bugs and data corruption.
|
||||
|
||||
|
||||
Python Runtime Model
|
||||
--------------------
|
||||
|
||||
The same conceptual layers apply to each Python program, with some
|
||||
extra data layers specific to Python:
|
||||
|
||||
**host machine**
|
||||
**process** (global resources)
|
||||
Python global runtime (*state*)
|
||||
Python interpreter (*state*)
|
||||
**thread** (runs Python bytecode and “C-API”)
|
||||
Python thread *state*
|
||||
|
||||
At the conceptual level: when a Python program starts, it looks
|
||||
exactly like that diagram, with one of each. The runtime may grow to
|
||||
include multiple interpreters, and each interpreter may grow to
|
||||
include multiple thread states.
|
||||
|
||||
Note:
|
||||
|
||||
A Python implementation won’t necessarily implement the runtime
|
||||
layers distinctly or even concretely. The only exception is places
|
||||
where distinct layers are directly specified or exposed to users,
|
||||
like through the "threading" module.
|
||||
|
||||
Note:
|
||||
|
||||
The initial interpreter is typically called the “main” interpreter.
|
||||
Some Python implementations, like CPython, assign special roles to
|
||||
the main interpreter.Likewise, the host thread where the runtime was
|
||||
initialized is known as the “main” thread. It may be different from
|
||||
the process’ initial thread, though they are often the same. In
|
||||
some cases “main thread” may be even more specific and refer to the
|
||||
initial thread state. A Python runtime might assign specific
|
||||
responsibilities to the main thread, such as handling signals.
|
||||
|
||||
As a whole, the Python runtime consists of the global runtime state,
|
||||
interpreters, and thread states. The runtime ensures all that state
|
||||
stays consistent over its lifetime, particularly when used with
|
||||
multiple host threads.
|
||||
|
||||
The global runtime, at the conceptual level, is just a set of
|
||||
interpreters. While those interpreters are otherwise isolated and
|
||||
independent from one another, they may share some data or other
|
||||
resources. The runtime is responsible for managing these global
|
||||
resources safely. The actual nature and management of these resources
|
||||
is implementation-specific. Ultimately, the external utility of the
|
||||
global runtime is limited to managing interpreters.
|
||||
|
||||
In contrast, an “interpreter” is conceptually what we would normally
|
||||
think of as the (full-featured) “Python runtime”. When machine code
|
||||
executing in a host thread interacts with the Python runtime, it calls
|
||||
into Python in the context of a specific interpreter.
|
||||
|
||||
Note:
|
||||
|
||||
The term “interpreter” here is not the same as the “bytecode
|
||||
interpreter”, which is what regularly runs in threads, executing
|
||||
compiled Python code.In an ideal world, “Python runtime” would refer
|
||||
to what we currently call “interpreter”. However, it’s been called
|
||||
“interpreter” at least since introduced in 1997 (CPython:a027efa5b).
|
||||
|
||||
Each interpreter completely encapsulates all of the non-process-
|
||||
global, non-thread-specific state needed for the Python runtime to
|
||||
work. Notably, the interpreter’s state persists between uses. It
|
||||
includes fundamental data like "sys.modules". The runtime ensures
|
||||
multiple threads using the same interpreter will safely share it
|
||||
between them.
|
||||
|
||||
A Python implementation may support using multiple interpreters at the
|
||||
same time in the same process. They are independent and isolated from
|
||||
one another. For example, each interpreter has its own "sys.modules".
|
||||
|
||||
For thread-specific runtime state, each interpreter has a set of
|
||||
thread states, which it manages, in the same way the global runtime
|
||||
contains a set of interpreters. It can have thread states for as many
|
||||
host threads as it needs. It may even have multiple thread states for
|
||||
the same host thread, though that isn’t as common.
|
||||
|
||||
Each thread state, conceptually, has all the thread-specific runtime
|
||||
data an interpreter needs to operate in one host thread. The thread
|
||||
state includes the current raised exception and the thread’s Python
|
||||
call stack. It may include other thread-specific resources.
|
||||
|
||||
Note:
|
||||
|
||||
The term “Python thread” can sometimes refer to a thread state, but
|
||||
normally it means a thread created using the "threading" module.
|
||||
|
||||
Each thread state, over its lifetime, is always tied to exactly one
|
||||
interpreter and exactly one host thread. It will only ever be used in
|
||||
that thread and with that interpreter.
|
||||
|
||||
Multiple thread states may be tied to the same host thread, whether
|
||||
for different interpreters or even the same interpreter. However, for
|
||||
any given host thread, only one of the thread states tied to it can be
|
||||
used by the thread at a time.
|
||||
|
||||
Thread states are isolated and independent from one another and don’t
|
||||
share any data, except for possibly sharing an interpreter and objects
|
||||
or other resources belonging to that interpreter.
|
||||
|
||||
Once a program is running, new Python threads can be created using the
|
||||
"threading" module (on platforms and Python implementations that
|
||||
support threads). Additional processes can be created using the "os",
|
||||
"subprocess", and "multiprocessing" modules. Interpreters can be
|
||||
created and used with the "interpreters" module. Coroutines (async)
|
||||
can be run using "asyncio" in each interpreter, typically only in a
|
||||
single thread (often the main thread).
|
||||
|
||||
-[ Footnotes ]-
|
||||
|
||||
[1] This limitation occurs because the code that is executed by these
|
||||
|
|
@ -5215,9 +5396,8 @@ class of the instance or a *non-virtual base class* thereof. The
|
|||
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".
|
||||
Unlike in integer literals, leading zeros are allowed. For example,
|
||||
"077.010" is legal, and denotes the same number as "77.01".
|
||||
|
||||
As in integer literals, single underscores may occur between digits to
|
||||
help readability:
|
||||
|
|
@ -6012,9 +6192,15 @@ def whats_on_the_telly(penguin=None):
|
|||
without "global", although free variables may refer to globals without
|
||||
being declared global.
|
||||
|
||||
The "global" statement applies to the entire scope of a function or
|
||||
class body. A "SyntaxError" is raised if a variable is used or
|
||||
assigned to prior to its global declaration in the scope.
|
||||
The "global" statement applies to the entire current scope (module,
|
||||
function body or class definition). A "SyntaxError" is raised if a
|
||||
variable is used or assigned to prior to its global declaration in the
|
||||
scope.
|
||||
|
||||
At the module level, all variables are global, so a "global" statement
|
||||
has no effect. However, variables must still not be used or assigned
|
||||
to prior to their "global" declaration. This requirement is relaxed in
|
||||
the interactive prompt (*REPL*).
|
||||
|
||||
**Programmer’s note:** "global" is a directive to the parser. It
|
||||
applies only to code parsed at the same time as the "global"
|
||||
|
|
@ -7028,9 +7214,8 @@ class body. A "SyntaxError" is raised if a variable is used or
|
|||
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".
|
||||
Unlike in integer literals, leading zeros are allowed. For example,
|
||||
"077.010" is legal, and denotes the same number as "77.01".
|
||||
|
||||
As in integer literals, single underscores may occur between digits to
|
||||
help readability:
|
||||
|
|
@ -7278,9 +7463,8 @@ class that has an "__rsub__()" method, "type(y).__rsub__(y, x)" is
|
|||
*************************
|
||||
|
||||
*Objects* are Python’s abstraction for data. All data in a Python
|
||||
program is represented by objects or by relations between objects. (In
|
||||
a sense, and in conformance to Von Neumann’s model of a “stored
|
||||
program computer”, code is also represented by objects.)
|
||||
program is represented by objects or by relations between objects.
|
||||
Even code is represented by objects.
|
||||
|
||||
Every object has an identity, a type and a value. An object’s
|
||||
*identity* never changes once it has been created; you may think of it
|
||||
|
|
@ -9742,10 +9926,14 @@ class is used in a class pattern with positional arguments, each
|
|||
the numeric index of a positional argument, or the name of a
|
||||
keyword argument. Returns a copy of the string where each
|
||||
replacement field is replaced with the string value of the
|
||||
corresponding argument.
|
||||
corresponding argument. For example:
|
||||
|
||||
>>> "The sum of 1 + 2 is {0}".format(1+2)
|
||||
'The sum of 1 + 2 is 3'
|
||||
>>> "The sum of 1 + 2 is {0}".format(1+2)
|
||||
'The sum of 1 + 2 is 3'
|
||||
>>> "The sum of {a} + {b} is {answer}".format(answer=1+2, a=1, b=2)
|
||||
'The sum of 1 + 2 is 3'
|
||||
>>> "{1} expects the {0} Inquisition!".format("Spanish", "Nobody")
|
||||
'Nobody expects the Spanish Inquisition!'
|
||||
|
||||
See Format String Syntax for a description of the various
|
||||
formatting options that can be specified in format strings.
|
||||
|
|
@ -9800,13 +9988,28 @@ class is used in a class pattern with positional arguments, each
|
|||
database as “Letter”, i.e., those with general category property
|
||||
being one of “Lm”, “Lt”, “Lu”, “Ll”, or “Lo”. Note that this is
|
||||
different from the Alphabetic property defined in the section 4.10
|
||||
‘Letters, Alphabetic, and Ideographic’ of the Unicode Standard.
|
||||
‘Letters, Alphabetic, and Ideographic’ of the Unicode Standard. For
|
||||
example:
|
||||
|
||||
>>> 'Letters and spaces'.isalpha()
|
||||
False
|
||||
>>> 'LettersOnly'.isalpha()
|
||||
True
|
||||
>>> 'µ'.isalpha() # non-ASCII characters can be considered alphabetical too
|
||||
True
|
||||
|
||||
See Unicode Properties.
|
||||
|
||||
str.isascii()
|
||||
|
||||
Return "True" if the string is empty or all characters in the
|
||||
string are ASCII, "False" otherwise. ASCII characters have code
|
||||
points in the range U+0000-U+007F.
|
||||
points in the range U+0000-U+007F. For example:
|
||||
|
||||
>>> 'ASCII characters'.isascii()
|
||||
True
|
||||
>>> 'µ'.isascii()
|
||||
False
|
||||
|
||||
Added in version 3.7.
|
||||
|
||||
|
|
@ -9815,8 +10018,16 @@ class is used in a class pattern with positional arguments, each
|
|||
Return "True" if all characters in the string are decimal
|
||||
characters and there is at least one character, "False" otherwise.
|
||||
Decimal characters are those that can be used to form numbers in
|
||||
base 10, e.g. U+0660, ARABIC-INDIC DIGIT ZERO. Formally a decimal
|
||||
character is a character in the Unicode General Category “Nd”.
|
||||
base 10, such as U+0660, ARABIC-INDIC DIGIT ZERO. Formally a
|
||||
decimal character is a character in the Unicode General Category
|
||||
“Nd”. For example:
|
||||
|
||||
>>> '0123456789'.isdecimal()
|
||||
True
|
||||
>>> '٠١٢٣٤٥٦٧٨٩'.isdecimal() # Arabic-Indic digits zero to nine
|
||||
True
|
||||
>>> 'alphabetic'.isdecimal()
|
||||
False
|
||||
|
||||
str.isdigit()
|
||||
|
||||
|
|
@ -9894,6 +10105,17 @@ class is used in a class pattern with positional arguments, each
|
|||
follow uncased characters and lowercase characters only cased ones.
|
||||
Return "False" otherwise.
|
||||
|
||||
For example:
|
||||
|
||||
>>> 'Spam, Spam, Spam'.istitle()
|
||||
True
|
||||
>>> 'spam, spam, spam'.istitle()
|
||||
False
|
||||
>>> 'SPAM, SPAM, SPAM'.istitle()
|
||||
False
|
||||
|
||||
See also "title()".
|
||||
|
||||
str.isupper()
|
||||
|
||||
Return "True" if all cased characters [4] in the string are
|
||||
|
|
@ -9914,7 +10136,15 @@ class is used in a class pattern with positional arguments, each
|
|||
Return a string which is the concatenation of the strings in
|
||||
*iterable*. A "TypeError" will be raised if there are any non-
|
||||
string values in *iterable*, including "bytes" objects. The
|
||||
separator between elements is the string providing this method.
|
||||
separator between elements is the string providing this method. For
|
||||
example:
|
||||
|
||||
>>> ', '.join(['spam', 'spam', 'spam'])
|
||||
'spam, spam, spam'
|
||||
>>> '-'.join('Python')
|
||||
'P-y-t-h-o-n'
|
||||
|
||||
See also "split()".
|
||||
|
||||
str.ljust(width, fillchar=' ', /)
|
||||
|
||||
|
|
@ -10124,6 +10354,8 @@ class is used in a class pattern with positional arguments, each
|
|||
>>> " foo ".split(maxsplit=0)
|
||||
['foo ']
|
||||
|
||||
See also "join()".
|
||||
|
||||
str.splitlines(keepends=False)
|
||||
|
||||
Return a list of the lines in the string, breaking at line
|
||||
|
|
@ -10256,6 +10488,8 @@ class is used in a class pattern with positional arguments, each
|
|||
>>> titlecase("they're bill's friends.")
|
||||
"They're Bill's Friends."
|
||||
|
||||
See also "istitle()".
|
||||
|
||||
str.translate(table, /)
|
||||
|
||||
Return a copy of the string in which each character has been mapped
|
||||
|
|
@ -11005,15 +11239,29 @@ class is used in a class pattern with positional arguments, each
|
|||
"except*" clause
|
||||
================
|
||||
|
||||
The "except*" clause(s) are used for handling "ExceptionGroup"s. The
|
||||
exception type for matching is interpreted as in the case of "except",
|
||||
but in the case of exception groups we can have partial matches when
|
||||
the type matches some of the exceptions in the group. This means that
|
||||
multiple "except*" clauses can execute, each handling part of the
|
||||
exception group. Each clause executes at most once and handles an
|
||||
exception group of all matching exceptions. Each exception in the
|
||||
group is handled by at most one "except*" clause, the first that
|
||||
matches it.
|
||||
The "except*" clause(s) specify one or more handlers for groups of
|
||||
exceptions ("BaseExceptionGroup" instances). A "try" statement can
|
||||
have either "except" or "except*" clauses, but not both. The exception
|
||||
type for matching is mandatory in the case of "except*", so "except*:"
|
||||
is a syntax error. The type is interpreted as in the case of "except",
|
||||
but matching is performed on the exceptions contained in the group
|
||||
that is being handled. An "TypeError" is raised if a matching type is
|
||||
a subclass of "BaseExceptionGroup", because that would have ambiguous
|
||||
semantics.
|
||||
|
||||
When an exception group is raised in the try block, each "except*"
|
||||
clause splits (see "split()") it into the subgroups of matching and
|
||||
non-matching exceptions. If the matching subgroup is not empty, it
|
||||
becomes the handled exception (the value returned from
|
||||
"sys.exception()") and assigned to the target of the "except*" clause
|
||||
(if there is one). Then, the body of the "except*" clause executes. If
|
||||
the non-matching subgroup is not empty, it is processed by the next
|
||||
"except*" in the same manner. This continues until all exceptions in
|
||||
the group have been matched, or the last "except*" clause has run.
|
||||
|
||||
After all "except*" clauses execute, the group of unhandled exceptions
|
||||
is merged with any exceptions that were raised or re-raised from
|
||||
within "except*" clauses. This merged exception group propagates on.:
|
||||
|
||||
>>> try:
|
||||
... raise ExceptionGroup("eg",
|
||||
|
|
@ -11026,20 +11274,19 @@ class is used in a class pattern with positional arguments, each
|
|||
caught <class 'ExceptionGroup'> with nested (TypeError(2),)
|
||||
caught <class 'ExceptionGroup'> with nested (OSError(3), OSError(4))
|
||||
+ Exception Group Traceback (most recent call last):
|
||||
| File "<stdin>", line 2, in <module>
|
||||
| ExceptionGroup: eg
|
||||
| File "<doctest default[0]>", line 2, in <module>
|
||||
| raise ExceptionGroup("eg",
|
||||
| [ValueError(1), TypeError(2), OSError(3), OSError(4)])
|
||||
| ExceptionGroup: eg (1 sub-exception)
|
||||
+-+---------------- 1 ----------------
|
||||
| ValueError: 1
|
||||
+------------------------------------
|
||||
|
||||
Any remaining exceptions that were not handled by any "except*" clause
|
||||
are re-raised at the end, along with all exceptions that were raised
|
||||
from within the "except*" clauses. If this list contains more than one
|
||||
exception to reraise, they are combined into an exception group.
|
||||
|
||||
If the raised exception is not an exception group and its type matches
|
||||
one of the "except*" clauses, it is caught and wrapped by an exception
|
||||
group with an empty message string.
|
||||
If the exception raised from the "try" block is not an exception group
|
||||
and its type matches one of the "except*" clauses, it is caught and
|
||||
wrapped by an exception group with an empty message string. This
|
||||
ensures that the type of the target "e" is consistently
|
||||
"BaseExceptionGroup":
|
||||
|
||||
>>> try:
|
||||
... raise BlockingIOError
|
||||
|
|
@ -11048,13 +11295,7 @@ class is used in a class pattern with positional arguments, each
|
|||
...
|
||||
ExceptionGroup('', (BlockingIOError()))
|
||||
|
||||
An "except*" clause must have a matching expression; it cannot be
|
||||
"except*:". Furthermore, this expression cannot contain exception
|
||||
group types, because that would have ambiguous semantics.
|
||||
|
||||
It is not possible to mix "except" and "except*" in the same "try".
|
||||
The "break", "continue", and "return" statements cannot appear in an
|
||||
"except*" clause.
|
||||
"break", "continue" and "return" cannot appear in an "except*" clause.
|
||||
|
||||
|
||||
"else" clause
|
||||
|
|
@ -11949,6 +12190,11 @@ class method object, it is transformed into an instance method object
|
|||
| | "X.__bases__" will be exactly equal to "(A, B, |
|
||||
| | C)". |
|
||||
+----------------------------------------------------+----------------------------------------------------+
|
||||
| type.__base__ | **CPython implementation detail:** The single base |
|
||||
| | class in the inheritance chain that is responsible |
|
||||
| | for the memory layout of instances. This attribute |
|
||||
| | corresponds to "tp_base" at the C level. |
|
||||
+----------------------------------------------------+----------------------------------------------------+
|
||||
| type.__doc__ | The class’s documentation string, or "None" if |
|
||||
| | undefined. Not inherited by subclasses. |
|
||||
+----------------------------------------------------+----------------------------------------------------+
|
||||
|
|
|
|||
2105
Misc/NEWS.d/3.14.1.rst
Normal file
2105
Misc/NEWS.d/3.14.1.rst
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -1,3 +0,0 @@
|
|||
Check the ``strftime()`` behavior at runtime instead of at the compile time
|
||||
to support cross-compiling.
|
||||
Remove the internal macro ``_Py_NORMALIZE_CENTURY``.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
``PYTHON_FOR_REGEN`` now requires Python 3.10 to Python 3.15.
|
||||
Patch by Adam Turner.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
When cross-compiling for WASI by ``build_wasm`` or ``build_emscripten``, the
|
||||
``build-details.json`` step is now included in the build process, just like
|
||||
with native builds.
|
||||
|
||||
This fixes the ``libinstall`` task which requires the ``build-details.json``
|
||||
file during the process.
|
||||
|
|
@ -1 +0,0 @@
|
|||
iOS builds were added to CI.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Generate a clear compilation error when ``_Py_TAIL_CALL_INTERP`` is enabled but
|
||||
either ``preserve_none`` or ``musttail`` is not supported.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Warn when the WASI SDK version doesn't match what's supported.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
Fix ``_remote_debugging_module.c`` compilation on 32-bit Linux. Include
|
||||
Python.h before system headers to make sure that
|
||||
``_remote_debugging_module.c`` uses the same types (ABI) than Python. Patch
|
||||
by Victor Stinner.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Do not generate the jit stencils twice in case of PGO builds on Windows.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
Add :c:func:`PyUnstable_ThreadState_SetStackProtection` and
|
||||
:c:func:`PyUnstable_ThreadState_ResetStackProtection` functions to set the
|
||||
stack protection base address and stack protection size of a Python thread
|
||||
state. Patch by Victor Stinner.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix :c:func:`Py_REFCNT` definition on limited C API 3.11-3.13. Patch by
|
||||
Victor Stinner.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix :c:macro:`Py_RETURN_NOTIMPLEMENTED` in limited C API 3.11 and older:
|
||||
don't treat ``Py_NotImplemented`` as immortal. Patch by Victor Stinner.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Make qNaN in :c:func:`PyFloat_Pack2` and :c:func:`PyFloat_Pack4`, if while
|
||||
conversion to a narrower precision floating-point format --- the remaining
|
||||
after truncation payload will be zero. Patch by Sergey B Kirpichev.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Removed the sqlite3_shutdown call that could cause closing connections for sqlite when used with multiple sub interpreters.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
Fix :term:`free threading` race condition in
|
||||
:c:func:`PyImport_AddModuleRef`. It was previously possible for two calls to
|
||||
the function return two different objects, only one of which was stored in
|
||||
:data:`sys.modules`.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix a crash when using threads inside of a subinterpreter.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fixed Ctrl+D (^D) behavior in _pyrepl module to match old pre-3.13 REPL behavior.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Improve performance of :class:`frozenset` by removing locks in the free-threading build.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Fix name of the Python encoding in Unicode errors of the code page codec:
|
||||
use "cp65000" and "cp65001" instead of "CP_UTF7" and "CP_UTF8" which are not
|
||||
valid Python code names. Patch by Victor Stinner.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
Fix a crash in the :term:`free threading` build when disabling profiling or
|
||||
tracing across all threads with :c:func:`PyEval_SetProfileAllThreads` or
|
||||
:c:func:`PyEval_SetTraceAllThreads` or their Python equivalents
|
||||
:func:`threading.settrace_all_threads` and
|
||||
:func:`threading.setprofile_all_threads`.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Fix a potential deadlock in the :term:`free threading` build when daemon
|
||||
threads enable or disable profiling or tracing while the main thread is
|
||||
shutting down the interpreter.
|
||||
|
|
@ -1 +0,0 @@
|
|||
On Solaris/Illumos platforms, thread names are now encoded as ASCII to avoid errors on systems (e.g. OpenIndiana) that don't support non-ASCII names.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Make :mod:`cProfile` thread-safe on the :term:`free threaded <free
|
||||
threading>` build.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix some standard library submodules missing from the :term:`REPL` auto-completion of imports.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Remove non-existent :meth:`~object.__copy__`, :meth:`~object.__deepcopy__`, and :attr:`~type.__bases__` from the :meth:`~object.__dir__` entries of :class:`types.GenericAlias`.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Fix :exc:`SyntaxError` message when invalid syntax appears on the same line
|
||||
as a valid ``import ... as ...`` or ``from ... import ... as ...``
|
||||
statement. Patch by Brian Schubert.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Don't run PyREPL in a degraded environment where setting termios attributes
|
||||
is not allowed.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix handling of unusual t-string annotations in annotationlib. Patch by Dave Peck.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Make :mod:`mmap` thread-safe on the :term:`free threaded <free threading>`
|
||||
build.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
Support non-UTF-8 shebang and comments in Python source files if non-UTF-8
|
||||
encoding is specified. Detect decoding error in comments for default (UTF-8)
|
||||
encoding. Show the line and position of decoding error for default encoding
|
||||
in a traceback. Show the line containing the coding cookie when it conflicts
|
||||
with the BOM in a traceback.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Fix swallowing some syntax warnings in different modules if they
|
||||
accidentally have the same message and are emitted from the same line.
|
||||
Fix duplicated warnings in the ``finally`` block.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
:func:`ast.parse` no longer emits syntax warnings for
|
||||
``return``/``break``/``continue`` in ``finally`` (see :pep:`765`) -- they are
|
||||
only emitted during compilation.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix lambda colon erroneously start format spec in f-string in tokenizer.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix reference leaks in error branches of functions accepting path strings or
|
||||
bytes such as :func:`compile` and :func:`os.system`. Patch by Bénédikt Tran.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix a memory leak when failing to create a :class:`~typing.Union` type.
|
||||
Patch by Bénédikt Tran.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Restore support for HP PA-RISC, which has an upwards-growing stack.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
Fix potential memory leak when a reference cycle exists between an instance
|
||||
of :class:`typing.TypeAliasType`, :class:`typing.TypeVar`,
|
||||
:class:`typing.ParamSpec`, or :class:`typing.TypeVarTuple` and its
|
||||
``__name__`` attribute. Patch by Mikhail Efimov.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix memory leak in sub-interpreter creation.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fixing the checking of whether an object is uniquely referenced to ensure
|
||||
free-threaded compatibility. Patch by Sergey Miryanov.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix a bug with exception handling in the JIT. Patch by Ken Jin. Bug reported
|
||||
by Daniel Diniz.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
Fixes a regression in GC performance for a growing heap composed mostly of
|
||||
small tuples.
|
||||
|
||||
* Counts number of actually tracked objects, instead of trackable objects.
|
||||
This ensures that untracking tuples has the desired effect of reducing GC overhead.
|
||||
* Does not track most untrackable tuples during creation.
|
||||
This prevents large numbers of small tuples causing excessive GCs.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix data race between interpreter_clear() and take_gil() on eval_breaker
|
||||
during finalization with daemon threads.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix memory leak of ``PyConfig`` in subinterpreters.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix memory leaks in cross-interpreter channel operations and shared
|
||||
namespace handling.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
Restore elapsed time and unreachable object count in GC debug output. These
|
||||
were inadvertently removed during a refactor of ``gc.c``. The debug log now
|
||||
again reports elapsed collection time and the number of unreachable objects.
|
||||
Contributed by Pål Grønås Drange.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix memory leak when an object's :meth:`~object.__hash__` method returns an
|
||||
object that isn't an :class:`int`.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
Fix memory leaks in :mod:`readline` functions
|
||||
:func:`~readline.read_init_file`, :func:`~readline.read_history_file`,
|
||||
:func:`~readline.write_history_file`, and
|
||||
:func:`~readline.append_history_file` when :c:func:`PySys_Audit` fails.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Fix a crash in Python's :term:`garbage collector <garbage collection>` due to
|
||||
partially initialized :term:`coroutine` objects when coroutine origin tracking
|
||||
depth is enabled (:func:`sys.set_coroutine_origin_tracking_depth`).
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix potential buffer overflow in :class:`ast.AST` node initialization when
|
||||
encountering malformed :attr:`~ast.AST._fields` containing non-:class:`str`.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Fixed a reference leak when iterating over the result of :func:`map`
|
||||
with ``strict=True`` when the input iterables have different lengths.
|
||||
Patch by Mikhail Efimov.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fixed crash in :class:`dict` if :meth:`dict.clear` is called at the lookup
|
||||
stage. Patch by Mikhail Efimov and Inada Naoki.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fixed crash in :func:`tokenize.generate_tokens` in case of
|
||||
specific incorrect input. Patch by Mikhail Efimov.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Correctly emit ``PY_UNWIND`` event when generator object is closed. Patch by
|
||||
Mikhail Efimov.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix a reference leak when ``raise exc from cause`` fails. Patch by Bénédikt
|
||||
Tran.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix :mod:`struct` data race in endian table initialization with
|
||||
subinterpreters. Patch by Shamil Abdulaev.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix memory leak when :class:`bytearray` or :class:`bytes` is formated with the
|
||||
``%*b`` format with a large width that results in a :exc:`MemoryError`.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Make csv module thread-safe on the :term:`free threaded <free threading>`
|
||||
build.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix the assertion failure in the ``__setstate__`` method of the range iterator
|
||||
when a non-integer argument is passed. Patch by Sergey Miryanov.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Suggest using :meth:`concurrent.interpreters.Interpreter.close` instead of the
|
||||
private ``_interpreters.destroy`` function when warning about remaining subinterpreters.
|
||||
Patch by Sergey Miryanov.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Skip locking if object is already locked by two-mutex critical section.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix :func:`sys.activate_stack_trampoline` to properly support the
|
||||
``perf_jit`` backend. Patch by Pablo Galindo.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Improve multithreaded scaling of dataclasses on the free-threaded build.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
Only raise a ``RecursionError`` or trigger a fatal error if the stack
|
||||
pointer is both below the limit pointer *and* above the stack base. If
|
||||
outside of these bounds assume that it is OK. This prevents false positives
|
||||
when user-space threads swap stacks.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix inconsistent state when enabling or disabling monitoring events too many
|
||||
times.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
When importing a module, use Python's regular file object to ensure that
|
||||
writes to ``.pyc`` files are complete or an appropriate error is raised.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix thread safety issue with :mod:`re` scanner objects in free-threaded
|
||||
builds.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix quadratically increasing garbage collection delays in free-threaded
|
||||
build.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Remove outdated sencence in the documentation for :mod:`multiprocessing`,
|
||||
that implied that :class:`concurrent.futures.ThreadPoolExecutor` did not
|
||||
exist.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
:mod:`xml.sax.handler`: Make Documentation of
|
||||
:data:`xml.sax.handler.feature_external_ges` warn of opening up to `external
|
||||
entity attacks <https://en.wikipedia.org/wiki/XML_external_entity_attack>`_.
|
||||
Patch by Sebastian Pipping.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Colorize t-string prefixes for template strings in IDLE, as done for f-string prefixes.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Deduplicate version number in IDLE shell title bar after saving to a file.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Allow negative priority values from :func:`os.sched_get_priority_min` and
|
||||
:func:`os.sched_get_priority_max` functions.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix failure when importing a module from the root directory on unix-like
|
||||
platforms with sys.pycache_prefix set.
|
||||
|
|
@ -1 +0,0 @@
|
|||
UTF8 support for the IMAP APPEND command has been made RFC compliant.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Clarify constraints for "logical" arguments in methods of
|
||||
:class:`decimal.Context`.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix potential hang in ``multiprocessing.popen_spawn_posix`` that can happen
|
||||
when the child proc dies early by closing the child fds right away.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Make ``ResourceTracker.send`` from :mod:`multiprocessing` re-entrant safe
|
||||
|
|
@ -1 +0,0 @@
|
|||
Make :class:`io.BytesIO` safe in :term:`free-threaded <free threading>` build.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix libc thread safety issues with :mod:`dbm` by performing stateful
|
||||
operations in critical sections.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix unpickling of :mod:`pathlib` objects that were pickled in Python 3.13.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix thread safety of :class:`collections.OrderedDict`. Patch by Kumar Aditya.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix a crash when calling methods of :class:`ssl.SSLContext` or
|
||||
:class:`ssl.SSLSocket` across multiple threads.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
Fixed :func:`subprocess.Popen.communicate` ``input=`` handling of :class:`memoryview`
|
||||
instances that were non-byte shaped on POSIX platforms. Those are now properly
|
||||
cast to a byte shaped view instead of truncating the input. Windows platforms
|
||||
did not have this bug.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
:mod:`email`: Fix exception in ``set_content()`` when encoding text
|
||||
and max_line_length is set to ``0`` or ``None`` (unlimited).
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix :mod:`multiprocessing` ``forkserver`` bug which prevented ``__main__``
|
||||
from being preloaded.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix :meth:`asyncio.DatagramTransport.sendto` to account for datagram header size when
|
||||
data cannot be sent.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix opening a :mod:`dbm.sqlite3` database for reading from read-only file
|
||||
or directory.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fixed the bug in :mod:`pdb` and :mod:`bdb` where ``next`` and ``step`` can't go over the line if a loop exists in the line.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Fix mimetypes CLI to handle multiple file parameters.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix :meth:`asyncio.WriteTransport.writelines` to be robust to connection
|
||||
failure, by using the same behavior as :meth:`~asyncio.WriteTransport.write`.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Allows creating a :class:`ctypes.CDLL` without name when passing a handle as
|
||||
an argument.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
:func:`hmac.digest` now properly handles large keys and messages
|
||||
by falling back to the pure Python implementation when necessary.
|
||||
Patch by Bénédikt Tran.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix retrieval of :attr:`doctest.DocTest.lineno` for objects decorated with
|
||||
:func:`functools.cache` or :class:`functools.cached_property`.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Fix a potential async-signal-safety issue in :mod:`faulthandler` when
|
||||
printing C stack traces.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
:class:`tarfile.TarFile` now accepts a :term:`path-like <path-like object>` when working on a tar archive.
|
||||
(Contributed by Alexander Enrique Urieles Nieto in :gh:`81325`.)
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue