PidfdChildWatcher removed without deprecation

[allisonkarlitskaya]

Bug report

Bug description:

hi

We got a bug report that our software isn't working with Python 3.14 prereleases: https://bugzilla.redhat.com/show_bug.cgi?id=2350287

That's caused by this issue removing a publicly documented API which (as per the current official documentation) was not deprecated or slated for removal:

#120893

https://docs.python.org/3/library/asyncio-policy.html#asyncio.PidfdChildWatcher

I kinda get the intent that the entire abstract child watcher approach was intended to be deprecated, but that's not how it was advertised in the official docs. We went out of our way to try to use the new API if available and fall back to the old deprecated API only if the new one wasn't available. Having both pulled out in the same release has just broken our code.

Please add this back.

CPython versions tested on:

3.14

Operating systems tested on:

Linux

[kumaraditya303]

That's caused by this issue removing a publicly documented API which (as per the current official documentation) was not deprecated or slated for removal:

The whole child watcher subsystem of asyncio was deprecated and slated for removal in 3.14. Specifically the functions to the set and get the child watchers i.e. get_child_watcher and set_child_watcher were deprecated and removed.

The code in question is incorrect, it should check the presence of set_child_watcher along side checking for watcher as just creating a watcher without being able to set it has no use.

[allisonkarlitskaya]

The whole child watcher subsystem of asyncio was deprecated and slated for removal in 3.14.

Do you mean that it was both deprecated and removed in the 3.14 development cycle (ie: without advance warning)?

Specifically the functions to the set and get the child watchers i.e. get_child_watcher and set_child_watcher were deprecated and removed.

We're not using either of those functions. We're just creating a PidfdChildWatcher and calling .add_child_handler() on it. It was working nicely for us that way before it was removed.

[kumaraditya303]

Do you mean that it was both deprecated and removed in the 3.14 development cycle (ie: without advance warning)?

It was deprecated since 3.12 and removed in 3.14

We're not using either of those functions. We're just creating a PidfdChildWatcher and calling .add_child_handler() on it. It was working nicely for us that way before it was removed.

The way to use a child watcher is to set it after creating it as per documented here https://docs.python.org/3.13/library/asyncio-policy.html#process-watchers

FWIW the easiest fix would be to avoid creating child watcher at all as in versions 3.12+ the best child watcher is used automatically as suggested here https://docs.python.org/3/whatsnew/3.12.html#asyncio

[allisonkarlitskaya]

Our issue is that we still need to retain compatibility all the way back to Python 3.6 and to kernel versions where pidfds are not available.

I'm also concerned about people trying to use existing version of our software with new versions of Python: even if we add a workaround now, we're not going to backport that workaround to previous versions. Older versions of our software are packaged in a large number of Linux distributions. One of the features of our software involves connecting to remote systems and running python3 from the PATH and injecting itself into that system. This has the potential to get pretty messy if that python3 ends up being 3.14...

[kumaraditya303]

Our issue is that we still need to retain compatibility all the way back to Python 3.6 and to kernel versions where pidfds are not available.

That's what I suggested above to configure child watcher in <3.12, on 3.12+ let asyncio handle it and it will do the right thing if kernel supports it.

I'm also concerned about people trying to use existing version of our software with new versions of Python: even if we add a workaround now, we're not going to backport that workaround to previous versions. Older versions of our software are packaged in a large number of Linux distributions. One of the features of our software involves connecting to remote systems and running python3 from the PATH and injecting itself into that system. This has the potential to get pretty messy if that python3 ends up being 3.14...

Your code also uses SafeChildWatcher as fallback which is also removed so your code will not work anyways on newer Python versions.

[allisonkarlitskaya]

Your code also uses SafeChildWatcher as fallback which is also removed so your code will not work anyways on newer Python versions.

We only try to use SafeChildWatcher if PidfdChildWatcher is missing (ie: for very old Python versions).

We specifically did that because SafeChildWatcher was deprecated and slated for removal...

[kumaraditya303]

We only try to use SafeChildWatcher if PidfdChildWatcher is missing (ie: for very old Python versions).
We specifically did that because SafeChildWatcher was deprecated and slated for removal...

The version of Python doesn't matter, if the kernel is old enough, then it would fallback to SafeChildWatcher which would break anyways.

[allisonkarlitskaya]

Although that's strictly true, we don't have any supported systems with Python 3.14 and a kernel not supporting pidfd (and I doubt that any such systems exist anywhere...).

[kumaraditya303]

I am closing this as it is the intended behavior.