8000 Merge branch 'main' into tstrings · python/cpython@c833f6d · GitHub
[go: up one dir, main page]
Skip to content

Commit c833f6d

Browse files
lysnikolaoulysnikolaou
committed
Merge branch 'main' into tstrings
2 parents 92fd148 + e42bda9 commit c833f6d

File tree

195 files changed

+2783
-1400
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

195 files changed

+2783
-1400
lines changed

‎.editorconfig

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
root = true
22

3-
[*.{py,c,cpp,h,js,rst,md,yml}]
3+
[*.{py,c,cpp,h,js,rst,md,yml,yaml}]
44
trim_trailing_whitespace = true
55
insert_final_newline = true
66
indent_style = space
@@ -11,5 +11,5 @@ indent_size = 4
1111
[*.rst]
1212
indent_size = 3
1313

14-
[*.{js,yml}]
14+
[*.{js,yml,yaml}]
1515
indent_size = 2

‎.github/actionlint.yaml

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,6 @@
11
self-hosted-runner:
2-
labels: ["windows-aarch64"]
2+
# Pending https://github.com/rhysd/actionlint/issues/533
3+
labels: ["windows-11-arm"]
34

45
config-variables: null
56

‎.github/workflows/build.yml

Lines changed: 6 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -156,28 +156,18 @@ jobs:
156156
strategy:
157157
fail-fast: false
158158
matrix:
159-
os:
160-
- win 10000 dows-latest
161159
arch:
162160
- x64
161+
- Win32
162+
- arm64
163163
free-threading:
164164
- false
165165
- true
166-
include:
167-
# Forks don't have access to Windows on Arm runners. These jobs are skipped below:
168-
- os: ${{ github.repository_owner == 'python' && 'windows-aarch64' || 'windows-latest' }}
169-
arch: arm64
170-
free-threading: false
171-
# Forks don't have access to Windows on Arm runners. These jobs are skipped below:
172-
- os: ${{ github.repository_owner == 'python' && 'windows-aarch64' || 'windows-latest' }}
173-
arch: arm64
174-
free-threading: true
175-
- os: windows-latest
176-
arch: Win32
177-
free-threading: false
166+
exclude:
167+
# Skip Win32 on free-threaded builds
168+
- { arch: Win32, free-threading: true }
178169
uses: ./.github/workflows/reusable-windows.yml
179170
with:
180-
os: ${{ matrix.os }}
181171
arch: ${{ matrix.arch }}
182172
free-threading: ${{ matrix.free-threading }}
183173

@@ -189,18 +179,12 @@ jobs:
189179
strategy:
190180
fail-fast: false
191181
matrix:
192-
os:
193-
- windows-latest
194182
arch:
195183
- x86
196184
- x64
197-
include:
198-
# Forks don't have access to Windows on Arm runners. These jobs are skipped below:
199-
- os: ${{ github.repository_owner == 'python' && 'windows-aarch64' || 'windows-latest' }}
200-
arch: arm64
185+
- arm64
201186
uses: ./.github/workflows/reusable-windows-msi.yml
202187
with:
203-
os: ${{ matrix.os }}
204188
arch: ${{ matrix.arch }}
205189

206190
build-macos:

‎.github/workflows/jit.yml

Lines changed: 2 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -74,8 +74,7 @@ jobs:
7474
runner: windows-latest
7575
- target: aarch64-pc-windows-msvc/msvc
7676
architecture: ARM64
77-
# Forks don't have access to Windows on Arm runners. These jobs are skipped below:
78-
runner: ${{ github.repository_owner == 'python' && 'windows-aarch64' || 'windows-latest' }}
77+
runner: windows-11-arm
7978
- target: x86_64-apple-darwin/clang
8079
architecture: x86_64
8180
runner: macos-13
@@ -97,8 +96,7 @@ jobs:
9796
python-version: '3.11'
9897

9998
- name: Windows
100-
# Forks don't have access to Windows on Arm runners. Skip those:
101-
if: runner.os == 'Windows' && (matrix.architecture != 'ARM64' || github.repository_owner == 'python')
99+
if: runner.os == 'Windows'
102100
run: |
103101
choco install llvm --allow-downgrade --no-progress --version ${{ matrix.llvm }}.1.0
104102
./PCbuild/build.bat --experimental-jit ${{ matrix.debug && '-d' || '' }} -p ${{ matrix.architecture }}

‎.github/workflows/reusable-windows-msi.yml

Lines changed: 1 addition & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -3,10 +3,6 @@ name: Reusable Windows MSI
33
on:
44
workflow_call:
55
inputs:
6-
os:
7-
description: OS to run on
8-
required: true
9-
type: string
106
arch:
117
description: CPU architecture
128
required: true
@@ -21,7 +17,7 @@ env:
2117
jobs:
2218
build:
2319
name: installer for ${{ inputs.arch }}
24-
runs-on: ${{ inputs.os }}
20+
runs-on: ${{ inputs.arch == 'arm64' && 'windows-11-arm' || 'windows-latest' }}
2521
timeout-minutes: 60
2622
env:
2723
ARCH: ${{ inputs.arch }}
@@ -31,7 +27,5 @@ jobs:
3127
with:
3228
persist-credentials: false
3329
- name: Build CPython installer
34-
# Forks don't have access to Windows on Arm runners. Skip those:
35-
if: inputs.arch != 'arm64' || github.repository_owner == 'python'
3630
run: ./Tools/msi/build.bat --doc -"${ARCH}"
3731
shell: bash

‎.github/workflows/reusable-windows.yml

Lines changed: 1 addition & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -3,10 +3,6 @@ name: Reusable Windows
33
on:
44
workflow_call:
55
inputs:
6-
os:
7-
description: OS to run on
8-
required: true
9-
type: string
106
arch:
117
description: CPU architecture
128
required: true
@@ -25,7 +21,7 @@ env:
2521
jobs:
2622
build:
2723
name: Build and test (${{ inputs.arch }})
28-
runs-on: ${{ inputs.os }}
24+
runs-on: ${{ inputs.arch == 'arm64' && 'windows-11-arm' || 'windows-latest' }}
2925
timeout-minutes: 60
3026
env:
3127
ARCH: ${{ inputs.arch }}
@@ -37,21 +33,15 @@ jobs:
3733
if: inputs.arch != 'Win32'
3834
run: echo "::add-matcher::.github/problem-matchers/msvc.json"
3935
- name: Build CPython
40-
# Forks don't have access to Windows on Arm runners. Skip those:
41-
if: inputs.arch != 'arm64' || github.repository_owner == 'python'
4236
run: >-
4337
.\\PCbuild\\build.bat
4438
-e -d -v
4539
-p "${ARCH}"
4640
${{ fromJSON(inputs.free-threading) && '--disable-gil' || '' }}
4741
shell: bash
4842
- name: Display build info
49-
# Forks don't have access to Windows on Arm runners. Skip those:
50-
if: inputs.arch != 'arm64' || github.repository_owner == 'python'
5143
run: .\\python.bat -m test.pythoninfo
5244
- name: Tests
53-
# Forks don't have access to Windows on Arm runners. Skip those:
54-
if: inputs.arch != 'arm64' || github.repository_owner == 'python'
5545
run: >-
5646
.\\PCbuild\\rt.bat
5747
-p "${ARCH}"

‎Doc/c-api/gcsupport.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -277,7 +277,7 @@ the garbage collector.
277277
278278
Type of the visitor function to be passed to :c:func:`PyUnstable_GC_VisitObjects`.
279279
*arg* is the same as the *arg* passed to ``PyUnstable_GC_VisitObjects``.
280-
Return ``0`` to continue iteration, return ``1`` to stop iteration. Other return
280+
Return ``1`` to continue iteration, return ``0`` to stop iteration. Other return
281281
values are reserved for now so behavior on returning anything else is undefined.
282282
283283
.. versionadded:: 3.12

‎Doc/c-api/typeobj.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -611,7 +611,7 @@ and :c:data:`PyType_Type` effectively act as defaults.)
611611
Note that the :c:member:`~PyVarObject.ob_size` field may later be used for
612612
other purposes. For example, :py:type:`int` instances use the bits of
613613
:c:member:`~PyVarObject.ob_size` in an implementation-defined
614-
way; the underlying storage and its size should be acessed using
614+
way; the underlying storage and its size should be accessed using
615615
:c:func:`PyLong_Export`.
616616

617617
.. note::

‎Doc/c-api/unicode.rst

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -596,6 +596,14 @@ APIs:
596596
Objects other than Unicode or its subtypes will cause a :exc:`TypeError`.
597597
598598
599+
.. c:function:: PyObject* PyUnicode_FromOrdinal(int ordinal)
600+
601+
Create a Unicode Object from the given Unicode code point *ordinal*.
602+
603+
The ordinal must be in ``range(0x110000)``. A :exc:`ValueError` is
604+
raised in the case it is not.
605+
606+
599607
.. c:function:: PyObject* PyUnicode_FromEncodedObject(PyObject *obj, \
600608
const char *encoding, const char *errors)
601609
@@ -622,7 +630,7 @@ APIs:
622630
623631
On error, set *\*p_left* to ``NULL`` and set an exception.
624632
625-
On sucess, set *\*p_left* to a new strong reference to the result.
633+
On success, set *\*p_left* to a new strong reference to the result.
626634
627635
628636
.. c:function:: void PyUnicode_AppendAndDel(PyObject **p_left, PyObject *right)

‎Doc/data/refcounts.dat

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2770,6 +2770,9 @@ PyUnicode_FromFormatV:PyObject*::+1:
27702770
PyUnicode_FromFormatV:const char*:format::
27712771
PyUnicode_FromFormatV:va_list:args::
27722772

2773+
PyUnicode_FromOrdinal:PyObject*::+1:
2774+
PyUnicode_FromOrdinal:int:ordinal::
2775+
27732776
PyUnicode_Append:void:::
27742777
PyUnicode_Append:PyObject**:p_left:0:
27752778
PyUnicode_Append:PyObject*:right::

‎Doc/deprecations/pending-removal-in-3.16.rst

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -32,7 +32,6 @@ Pending removal in Python 3.16
3232
* :class:`asyncio.WindowsProactorEventLoopPolicy`
3333
* :func:`asyncio.get_event_loop_policy`
3434
* :func:`asyncio.set_event_loop_policy`
35-
* :func:`asyncio.set_event_loop`
3635

3736
Users should use :func:`asyncio.run` or :class:`asyncio.Runner` with
3837
*loop_factory* to use the desired event loop implementation.

‎Doc/howto/free-threading-extensions.rst

Lines changed: 135 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -243,6 +243,141 @@ depend on your extension, but some common patterns include:
243243
`thread-local storage <https://en.cppreference.com/w/c/language/storage_duration>`_.
244244

245245

246+
Critical Sections
247+
=================
248+
249+
.. _critical-sections:
250+
251+
In the free-threaded build, CPython provides a mechanism called "critical
252+
sections" to protect data that would otherwise be protected by the GIL.
253+
While extension authors may not interact with the internal critical section
254+
implementation directly, understanding their behavior is crucial when using
255+
certain C API functions or managing shared state in the free-threaded build.
256+
257+
What Are Critical Sections?
258+
...........................
259+
260+
Conceptually, critical sections act as a deadlock avoidance layer built on
261+
top of simple mutexes. Each thread maintains a stack of active critical
262+
sections. When a thread needs to acquire a lock associated with a critical
263+
section (e.g., implicitly when calling a thread-safe C API function like
264+
:c:func:`PyDict_SetItem`, or explicitly using macros), it attempts to acquire
265+
the underlying mutex.
266+
267+
Using Critical Sections
268+
.......................
269+
270+
The primary APIs for using critical sections are:
271+
272+
* :c:macro:`Py_BEGIN_CRITICAL_SECTION` and :c:macro:`Py_END_CRITICAL_SECTION` -
273+
For locking a single object
274+
275+
* :c:macro:`Py_BEGIN_CRITICAL_SECTION2` and :c:macro:`Py_END_CRITICAL_SECTION2`
276+
- For locking two objects simultaneously
277+
278+
These macros must be used in matching pairs and must appear in the same C
279+
scope, since they establish a new local scope. These macros are no-ops in
280+
non-free-threaded builds, so they can be safely added to code that needs to
281+
support both build types.
282+
283+
A common use of a critical section would be to lock an object while accessing
284+
an internal attribute of it. For example, if an extension type has an internal
285+
count field, you could use a critical section while reading or writing that
286+
field::
287+
288+
// read the count, returns new reference to internal count value
289+
PyObject *result;
290+
Py_BEGIN_CRITICAL_SECTION(obj);
291+
result = Py_NewRef(obj->count);
292+
Py_END_CRITICAL_SECTION();
293+
return result;
294+
295+
// write the count, consumes reference from new_count
296+
Py_BEGIN_CRITICAL_SECTION(obj);
297+
obj->count = new_count;
298+
Py_END_CRITICAL_SECTION();
299+
300+
301+
How Critical Sections Work
302+
..........................
303+
304+
Unlike traditional locks, critical sections do not guarantee exclusive access
305+
throughout their entire duration. If a thread would block while holding a
306+
critical section (e.g., by acquiring another lock or performing I/O), the
307+
critical section is temporarily suspended—all locks are released—and then
308+
resumed when the blocking operation completes.
309+
310+
This behavior is similar to what happens with the GIL when a thread makes a
311+
blocking call. The key differences are:
312+
313+
* Critical sections operate on a per-object basis rather than globally
314+
315+
* Critical sections follow a stack discipline within each thread (the "begin" and
316+
"end" macros enforce this since they must be paired and within the same scope)
317+
318+
* Critical sections automatically release and reacquire locks around potential
319+
blocking operations
320+
321+
Deadlock Avoidance
322+
..................
323+
324+
Critical sections help avoid deadlocks in two ways:
325+
326+
1. If a thread tries to acquire a lock that's already held by another thread,
327+
it first suspends all of its active critical sections, temporarily releasing
328+
their locks
329+
330+
2. When the blocking operation completes, only the top-most critical section is
331+
reacquired first
332+
333+
This means you cannot rely on nested critical sections to lock multiple objects
334+
at once, as the inner critical section may suspend the outer ones. Instead, use
335+
:c:macro:`Py_BEGIN_CRITICAL_SECTION2` to lock two objects simultaneously.
336+
337+
Note that the locks described above are only :c:type:`!PyMutex` based locks.
338+
The critical section implementation does not know about or affect other locking
339+
mechanisms that might be in use, like POSIX mutexes. Also note that while
340+
blocking on any :c:type:`!PyMutex` causes the critical sections to be
341+
suspended, only the mutexes that are part of the critical sections are
342+
released. If :c:type:`!PyMutex` is used without a critical section, it will
343+
not be released and therefore does not get the same deadlock avoidance.
344+
345+
Important Considerations
346+
........................
347+
348+
* Critical sections may temporarily release their locks, allowing other threads
349+
to modify the protected data. Be careful about making assumptions about the
350+
state of the data after operations that might block.
351+
352+
* Because locks can be temporarily released (suspended), entering a critical
353+
section does not guarantee exclusive access to the protected resource
354+
throughout the section's duration. If code within a critical section calls
355+
another function that blocks (e.g., acquires another lock, performs blocking
356+
I/O), all locks held by the thread via critical sections will be released.
357+
This is similar to how the GIL can be released during blocking calls.
358+
359+
* Only the lock(s) associated with the most recently entered (top-most)
360+
critical section are guaranteed to be held at any given time. Locks for
361+
outer, nested critical sections might have been suspended.
362+
363+
* You can lock at most two objects simultaneously with these APIs. If you need
364+
to lock more objects, you'll need to restructure your code.
365+
366+
* While critical sections will not deadlock if you attempt to lock the same
367+
object twice, they are less efficient than purpose-built reentrant locks for
368+
this use case.
369+
370+
* When using :c:macro:`Py_BEGIN_CRITICAL_SECTION2`, the order of the objects
371+
doesn't affect correctness (the implementation handles deadlock avoidance),
372+
but it's good practice to always lock objects in a consistent order.
373+
374+
* Remember that the critical section macros are primarily for protecting access
375+
to *Python objects* that might be involved in internal CPython operations
376+
susceptible to the deadlock scenarios described above. For protecting purely
377+
internal extension state, standard mutexes or other synchronization
378+
primitives might be more appropriate.
379+
380+
246381
Building Extensions for the Free-Threaded Build
247382
===============================================
248383

‎Doc/howto/logging-cookbook.rst

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -626,6 +626,19 @@ which, when run, will produce:
626626
of each message with the handler's level, and only passes a message to a
627627
handler if it's appropriate to do so.
628628

629+
.. versionchanged:: next
630+
The :class:`QueueListener` can be started (and stopped) via the
631+
:keyword:`with` statement. For example:
632+
633+
.. code-block:: python
634+
635+
with QueueListener(que, handler) as listener:
636+
# The queue listener automatically starts
637+
# when the 'with' block is entered.
638+
pass
639+
# The queue listener automatically stops once
640+
# the 'with' block is exited.
641+
629642
.. _network-logging:
630643

631644
Sending and receiving logging events across a network

0 commit comments

Comments
 (0)
0