All commit authors signed the Contributor License Agreement.

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

I have created a NEWS entry for this fix, but actually this change has indeed a little impact on Python users, so maybe skip news tag is more appropriate here.

Many tests are failing with a warning - as now the DeprecationWarning is no longer hidden (and as I unedrstand it, the tests run with the equivalent of -Werror).

Many of the failing tests do not fail where one would expect to have more than one thread running. For example, in test_uuid.testIssue8621.

When printing there the number of threads using threading.active_count() we get 1. However, when investigating further, the number of threads are actually 2 - just that one of the threads is not a python thread, and therefore not counted by threading.active_count().

Therefore, we should find a way to suppress the warning of running a fork within a thread in all the tests that fail. Petr suggests to consider using the sys.unraisablehook (see https://vstinner.github.io/sys-unraisablehook-python38.html) in all the places where the tests fail.

If anyone knows where this extra thread comes from, it will be appreciated if this is explained :-)

If anyone knows where this extra thread comes from, it will be appreciated if this is explained :-)

That is ironically exactly why we have this warning - threads in a process can come from everywhere including external libraries outside of our control.

I do think you're on the right track in terms of how to enable this to be something -Werror captures. As a potentially disruptive behavior change for some test suites, it isn't a bug fix - but it'd make sense in 3.15. Having a news entry is indeed appropriate.

using sys.unraisablehook in these parts of the test suites is an interesting idea.

@encukou, @gpshead - I am not sure, but maybe we should indeed create two PRs. The one that is here for 3.15. And in the second PR we will not raise exceptions for these deprecation warnings when using -Werror, but just show the warnings. This other PR maybe then can go in 3.14 - so at least the deprecation warnings are shown in that release when we have -Werror.

I think that the differences between the two PRs will only be the change in Modules/posixmodule.c but all the decorators to ignore the warnings should be the same. So in the other PR the change will be as shown in this earlier commit.

What do you think?

I think this should go in 3.15 only, and go through the full testing period.
There's no removal date set for these DeprecationWarnings; if people see them one release later, there's not that much harm done.
The 3.14 branch is only accepts critical fixes for 3.14.0, and after that bugfixes for 3.14.1. Emitting new warnings in bugfix releases tends to be messy.

🤖 New build scheduled with the buildbot fleet by @encukou for commit 8b699d8 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F136796%2Fmerge

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

@rani-pinchuk, I think this is close to the finish line. Would you like me to fix up the remaining issue?

🤖 New build scheduled with the buildbot fleet by @encukou for commit baa8446 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F136796%2Fmerge

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