All commit authors signed the Contributor License Agreement.

Most changes to Pythonrequire a NEWS entry.

Please add it using theblurb_it web app or theblurb command-line tool.

🤖 New build scheduled with the buildbot fleet by@vsajip for commitefd7462 🤖

If you want to schedule another build, you need to add the🔨 test-with-buildbots label again.

I leave our logging expert to take the final decision

I'm away for a couple of weeks (with sporadic Internet access) and have set off tests in the buildbot fleet, with some results still to come in. If all the failures are unrelated to this change, I think we can merge this PR.

(...) have set off tests in the buildbot fleet, with some results still to come in. If all the failures are unrelated to this change, I think we can merge this PR.

Sadly, there are many unstable tests these days, I'm trying to fix most of them. I mean: most failures are unrelated to this PR. But someone has to check. Or later, you can rebase the PR on the main branch, and schedule a new buildbot job.

🤖 New build scheduled with the buildbot fleet by@AA-Turner for commit797ae0d 🤖

If you want to schedule another build, you need to add the🔨 test-with-buildbots label again.

Ubuntu reportsFAILURE then SUCCESS fortest.test_multiprocessing_spawn.test_processes

Ubuntu reports FAILURE then SUCCESS for test.test_multiprocessing_spawn.test_processes

There are many unstable tests. All "FAILURE then SUCCESS" are unstable tests. They are unrelated to this change and you can ignore them.

You can browse into my issueshttps://github.com/python/cpython/issues/vstinner to see recent unstable tests.

10 buildbots failed:

• FAILURE then FAILURE
  • PPC64 Fedora PR/1234 (test_sumprod_stress (test.test_math.MathTests.test_sumprod_stress) ... Timeout (0:15:00)!)
  • PPC64LE RHEL8 PR/1212 (test_pycfunction (test.test_gdb.PyBtTests.test_pycfunction) ... Timeout (0:15:00)!)
• FAILURE then SUCCESS:
  • AMD64 Debian root PR/1243
  • ARM64 macOS PR/1254
  • PPC64LE Fedora Stable Refleaks PR/1355
  • PPC64LE RHEL7 PR/1195
  • s390x RHEL8 PR/1210
• ENV CHANGED then SUCCESS
  • PPC64LE RHEL7 Refleaks PR/1387
  • PPC64LE RHEL8 Refleaks PR/1428
• Timed out
  • AMD64 Windows11 Refleaks PR/114:test.test_concurrent_futures.test_shutdown (after 2 hour 49 min)

None seem logging related, so seems safe to merge.

A

@vsajip, maintainer of logging wrote:

I'm away for a couple of weeks (with sporadic Internet access) and have set off tests in the buildbot fleet, with some results still to come in. If all the failures are unrelated to this change, I think we can merge this PR.

In short, he approved the PR.

Merged. Thanks@dcollison, it's a nice cleanup. It may make the logging safer, sincewith lock: is treated differently than thelock.acquire() try: ... finally: lock.release() pattern. Awith block doesn't handle signals at the bytecode level. To avoid messing a lock when a signal is received (like CTRL+C).

Example in Python 3.10, see also issuegh-74225:

if (_Py_atomic_load_relaxed(eval_breaker)) {opcode=_Py_OPCODE(*next_instr);if (opcode!=SETUP_FINALLY&&opcode!=SETUP_WITH&&opcode!=BEFORE_ASYNC_WITH&&opcode!=YIELD_FROM) {/* Few cases where we skip running signal handlers and other                   pending calls:                   - If we're about to enter the 'with:'. It will prevent                     emitting a resource warning in the common idiom                     'with open(path) as file:'.                   - If we're about to enter the 'async with:'.                   - If we're about to enter the 'try:' of a try/finally (not                     *very* useful, but might help in some cases and it's                     traditional)                   - If we're resuming a chain of nested 'yield from' or                     'await' calls, then each frame is parked with YIELD_FROM                     as its next opcode. If the user hit control-C we want to                     wait until we've reached the innermost frame before                     running the signal handler and raising KeyboardInterrupt                     (see bpo-30039).                */if (eval_frame_handle_pending(tstate)!=0) {                    gotoerror;                }             }        }

⚠️⚠️⚠️ Buildbot failure⚠️⚠️⚠️

Hi! The buildbotAMD64 Fedora Stable Clang 3.x has failed when building commit74723e1.

What do you need to do:

1. Don't panic.
2. Checkthe buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/441/builds/4565) and take a look at the build logs.
4. Check if the failure is related to this commit (74723e1) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/441/builds/4565

Failed tests:

• test.test_multiprocessing_fork.test_processes

Summary of the results of the build (if available):

==

remote:Enumerating objects: 16, done.remote:Counting objects:   7% (1/14)remote:Counting objects:  14% (2/14)remote:Counting objects:  21% (3/14)remote:Counting objects:  28% (4/14)remote:Counting objects:  35% (5/14)remote:Counting objects:  42% (6/14)remote:Counting objects:  50% (7/14)remote:Counting objects:  57% (8/14)remote:Counting objects:  64% (9/14)remote:Counting objects:  71% (10/14)remote:Counting objects:  78% (11/14)remote:Counting objects:  85% (12/14)remote:Counting objects:  92% (13/14)remote:Counting objects: 100% (14/14)remote:Counting objects: 100% (14/14), done.remote:Compressing objects:  11% (1/9)remote:Compressing objects:  22% (2/9)remote:Compressing objects:  33% (3/9)remote:Compressing objects:  44% (4/9)remote:Compressing objects:  55% (5/9)remote:Compressing objects:  66% (6/9)remote:Compressing objects:  77% (7/9)remote:Compressing objects:  88% (8/9)remote:Compressing objects: 100% (9/9)remote:Compressing objects: 100% (9/9), done.remote:Total 16 (delta 5), reused 6 (delta 5), pack-reused 2From https://github.com/python/cpython * branch                  main       -> FETCH_HEADNote:switching to '74723e11109a320e628898817ab449b3dad9ee96'.You are in 'detached HEAD' state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by switching back to a branch.If you want to create a new branch to retain commits you create, you maydo so (now or later) by using -c with the switch command. Example:  git switch -c <new-branch-name>Or undo this operation with:  git switch -Turn off this advice by setting config variable advice.detachedHead to falseHEAD is now at 74723e1110 gh-109461: Update logging module lock to use context manager (#109462)Switched to and reset branch 'main'make:*** [Makefile:2040: buildbottest] Error 5

⚠️⚠️⚠️ Buildbot failure⚠️⚠️⚠️

Hi! The buildbotaarch64 Fedora Stable LTO + PGO 3.x has failed when building commit74723e1.

What do you need to do:

1. Don't panic.
2. Checkthe buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/524/builds/4572) and take a look at the build logs.
4. Check if the failure is related to this commit (74723e1) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/524/builds/4572

Summary of the results of the build (if available):

==

Traceback (most recent call last):  File"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.lto-pgo/build/Lib/threading.py", line1066, in_bootstrap_innerself.run()  File"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.lto-pgo/build/Lib/threading.py", line1003, inrunself._target(*self._args,**self._kwargs)  File"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.lto-pgo/build/Lib/test/test_interpreters.py", line483, intask    interp= interpreters.create()^^^^^^^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-aarch64.lto-pgo/build/Lib/test/support/interpreters.py", line25, increateid= _interpreters.create(isolated=isolated)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^RuntimeError:interpreter creation failedkTraceback (most recent call last):  File"<frozen importlib._bootstrap>", line1354, in_find_and_load  File"<frozen importlib._bootstrap>", line1325, in_find_and_load_unlocked  File"<frozen importlib._bootstrap>", line929, in_load_unlocked  File"<frozen importlib._bootstrap_external>", line1004, inexec_module  File"<frozen importlib._bootstrap_external>", line1100, inget_code  File"<frozen importlib._bootstrap_external>", line1199, inget_dataTypeError:descriptor 'close' for '_io.BufferedReader' objects doesn't apply to a '_io.FileIO' object