Skip to content

Commit d007911

Browse files
StanFromIrelandStanFromIreland
authored
Merge branch 'main' into issue-149083-2
2 parents b39d170 + 6040d65 commit d007911

25 files changed

Lines changed: 1516 additions & 1128 deletions

‎.github/workflows/posix-deps-apt.sh‎

Lines changed: 13 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -26,9 +26,16 @@ apt-get -yq --no-install-recommends install \
2626
xvfb \
2727
zlib1g-dev
2828

29-
# Workaround missing libmpdec-dev on ubuntu 24.04:
30-
# https://launchpad.net/~ondrej/+archive/ubuntu/php
31-
# https://deb.sury.org/
32-
sudo add-apt-repository ppa:ondrej/php
33-
apt-get update
34-
apt-get -yq --no-install-recommends install libmpdec-dev
29+
# Workaround missing libmpdec-dev on ubuntu 24.04 by building mpdecimal
30+
# from source. ppa:ondrej/php (launchpad.net) are unreliable
31+
# (https://status.canonical.com) so fetch the tarball directly
32+
# from the upstream host.
33+
# https://www.bytereef.org/mpdecimal/
34+
MPDECIMAL_VERSION=4.0.1
35+
curl -fsSL "https://www.bytereef.org/software/mpdecimal/releases/mpdecimal-${MPDECIMAL_VERSION}.tar.gz" \
36+
| tar -xz -C /tmp
37+
(cd "/tmp/mpdecimal-${MPDECIMAL_VERSION}" \
38+
&& ./configure --prefix=/usr/local \
39+
&& make -j"$(nproc)" \
40+
&& make install)
41+
ldconfig

‎Doc/library/compression.zstd.rst‎

Lines changed: 7 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -331,10 +331,14 @@ Compressing and decompressing data in memory
331331

332332
If *max_length* is non-negative, the method returns at most *max_length*
333333
bytes of decompressed data. If this limit is reached and further
334-
output can be produced, the :attr:`~.needs_input` attribute will
335-
be set to ``False``. In this case, the next call to
334+
output can be produced (or EOF is reached), the :attr:`~.needs_input`
335+
attribute will be set to ``False``. In this case, the next call to
336336
:meth:`~.decompress` may provide *data* as ``b''`` to obtain
337-
more of the output.
337+
more of the output. The full content can thus be read like::
338+
339+
process_output(d.decompress(data, max_length))
340+
while not d.eof and not d.needs_input:
341+
process_output(d.decompress(b"", max_length))
338342

339343
If all of the input data was decompressed and returned (either
340344
because this was less than *max_length* bytes, or because

‎Doc/library/email.policy.rst‎

Lines changed: 17 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -403,11 +403,26 @@ added matters. To illustrate::
403403
.. attribute:: utf8
404404

405405
If ``False``, follow :rfc:`5322`, supporting non-ASCII characters in
406-
headers by encoding them as "encoded words". If ``True``, follow
407-
:rfc:`6532` and use ``utf-8`` encoding for headers. Messages
406+
headers by encoding them as :rfc:`2047` "encoded words". If ``True``,
407+
follow :rfc:`6532` and use ``utf-8`` encoding for headers. Messages
408408
formatted in this way may be passed to SMTP servers that support
409409
the ``SMTPUTF8`` extension (:rfc:`6531`).
410410

411+
When ``False``, the generator will raise
412+
:exc:`~email.errors.HeaderWriteError` if any header includes non-ASCII
413+
characters in a context where :rfc:`2047` does not permit encoded words.
414+
This particularly applies to mailboxes ("addr-spec") with non-ASCII
415+
characters, which can be created via
416+
:class:`~email.headerregistry.Address`. To use a mailbox with a non-ASCII
417+
domain name with ``utf8=False``, first encode the domain using the
418+
third-party :pypi:`idna` or :pypi:`uts46` module or with
419+
:mod:`encodings.idna`. It is not possible to use a non-ASCII username
420+
("local-part") in a mailbox when ``utf8=False``.
421+
422+
.. versionchanged:: 3.15
423+
Can trigger the raising of :exc:`~email.errors.HeaderWriteError`.
424+
(Earlier versions incorrectly applied :rfc:`2047` in certain contexts,
425+
mostly notably in addr-specs.)
411426

412427
.. attribute:: refold_source
413428

‎Doc/library/zlib.rst‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -308,6 +308,11 @@ Decompression objects support the following methods and attributes:
308308
:attr:`unconsumed_tail`. This bytestring must be passed to a subsequent call to
309309
:meth:`decompress` if decompression is to continue. If *max_length* is zero
310310
then the whole input is decompressed, and :attr:`unconsumed_tail` is empty.
311+
For example, the full content could be read like::
312+
313+
process_output(d.decompress(data, max_length))
314+
while chunk := d.decompress(d.unconsumed_tail, max_length):
315+
process_output(chunk)
311316

312317
.. versionchanged:: 3.6
313318
*max_length* can be used as a keyword argument.

‎Doc/whatsnew/3.14.rst‎

Lines changed: 42 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -953,10 +953,24 @@ when a module is imported) will still emit the syntax warning.
953953
(Contributed by Irit Katriel in :gh:`130080`.)
954954

955955

956+
.. _incremental-garbage-collection:
956957
.. _whatsnew314-incremental-gc:
957958

958-
Incremental garbage collection
959-
------------------------------
959+
Garbage collection
960+
------------------
961+
962+
**From Python 3.14.5 onwards:**
963+
964+
The garbage collector (GC) has changed in Python 3.14.5.
965+
966+
Python 3.14.0-3.14.4 shipped with a new incremental GC.
967+
However, due to a number of `reports
968+
<https://github.com/python/cpython/issues/142516>`__
969+
of significant memory pressure in production environments,
970+
it has been reverted back to the generational GC from 3.13.
971+
This is the GC now used in Python 3.14.5 and later.
972+
973+
**Previously in Python 3.14.0-3.14.4:**
960974

961975
The cycle garbage collector is now incremental.
962976
This means that maximum pause times are reduced
@@ -2203,7 +2217,18 @@ difflib
22032217
gc
22042218
--
22052219

2206-
* The new :ref:`incremental garbage collector <whatsnew314-incremental-gc>`
2220+
* **From Python 3.14.5 onwards:**
2221+
2222+
Python 3.14.0-3.14.4 shipped with a new incremental garbage collector.
2223+
However, due to a number of `reports
2224+
<https://github.com/python/cpython/issues/142516>`__
2225+
of significant memory pressure in production environments,
2226+
it has been reverted back to the generational GC from 3.13.
2227+
This is the GC now used in Python 3.14.5 and later.
2228+
2229+
* **Previously in Python 3.14.0-3.14.4:**
2230+
2231+
The new :ref:`incremental garbage collector <whatsnew314-incremental-gc>`
22072232
means that maximum pause times are reduced
22082233
by an order of magnitude or more for larger heaps.
22092234

@@ -3447,3 +3472,17 @@ Changes in the C API
34473472
functions on Python 3.13 and older.
34483473

34493474
.. _pythoncapi-compat project: https://github.com/python/pythoncapi-compat/
3475+
3476+
3477+
Notable changes in 3.14.5
3478+
=========================
3479+
3480+
gc
3481+
--
3482+
3483+
* The incremental garbage collector shipped in Python 3.14.0-3.14.4 has been
3484+
reverted back to the generational garbage collector from 3.13,
3485+
due to a number of `reports
3486+
<https://github.com/python/cpython/issues/142516>`__
3487+
of significant memory pressure in production environments.
3488+
See :ref:`whatsnew314-incremental-gc` for details.

‎Doc/whatsnew/3.15.rst‎

Lines changed: 12 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -914,6 +914,16 @@ faulthandler
914914
(Contributed by Eric Froemling in :gh:`149085`.)
915915

916916

917+
email
918+
-----
919+
920+
* Email generators now raise an error when an :class:`.EmailMessage` cannot be
921+
accurately flattened due to a non-ASCII email address (mailbox) in an address
922+
header. Options for supporting Email Address Internationalization (EAI) are
923+
discussed in :attr:`.EmailPolicy.utf8`.
924+
(Contributed by R David Murray and Mike Edmunds in :gh:`122540`.)
925+
926+
917927
functools
918928
---------
919929

@@ -1579,11 +1589,11 @@ Upgraded JIT compiler
15791589

15801590
Results from the `pyperformance <https://github.com/python/pyperformance>`__
15811591
benchmark suite report
1582-
`6-7% <https://www.doesjitgobrrr.com/run/2026-04-01>`__
1592+
`8-9% <https://www.doesjitgobrrr.com/run/2026-04-29>`__
15831593
geometric mean performance improvement for the JIT over the standard CPython
15841594
interpreter built with all optimizations enabled on x86-64 Linux. On AArch64
15851595
macOS, the JIT has a
1586-
`12-13% <https://www.doesjitgobrrr.com/run/2026-04-01>`__
1596+
`12-13% <https://www.doesjitgobrrr.com/run/2026-04-29>`__
15871597
speedup over the :ref:`tail calling interpreter <whatsnew314-tail-call-interpreter>`
15881598
with all optimizations enabled. The speedups for JIT
15891599
builds versus no JIT builds range from roughly 15% slowdown to over

0 commit comments

Comments
 (0)