gh-110397: Add Py_IsFinalizing() to the stable ABI#110441
Conversation
|
@ericsnowcurrently @serhiy-storchaka: @wjakob explains that reimplementing this function with the existing limited C API is likely to crash if calling during or after Python finalization. See: #110397 (comment) Would you be ok to add Py_IsFinalizing() directly to the limited C API version 3.13, knowing that this function was added to Python 3.13? This Py_IsFinalizing() function looks special and it's hard to workaround the lack of this API with the stable ABI. |
Sorry, something went wrong.
|
I'm fine with adding it to the Stable ABI, FWIW. |
Sorry, something went wrong.
|
FWIW, before we add the function to the stable ABI, it may be worth being clear about what "finalizing" means here. Consequently, we should consider actually making the I've written up my thoughts in detail in gh-110490. I realize that the stable ABI (and limited API) are specifically focused on memory layout, function signatures, and symbols (so it isn't critical if we change behavior later). Yet, there is also an implication of semantic stability (within reason) that we should avoid setting ourselves up to later break with this function. On the other hand, a different name might make sense, so we should avoid locking the symbol into the ABI prematurely. |
Sorry, something went wrong.
This API is just the same as |
Sorry, something went wrong.
|
@ericsnowcurrently: I merged this PR since I'm feeling responsible of breaking applications relying on Python 3.12 private _Py_IsFinalizing() API. This C API exposes Python For sure, there is always room for enhancement. It's a very complex topic, I wrote articles about it and I'm keeping notes about it: Python Finalization. While it's possible to enhance the API, make finalization more reliable, reduce the risk of crashes, IMO we need "something" for people who are already affected by known issues. @wjakob elaborated issues that this API is solving in #110397 (comment) and just for that, I think that such API is worth it. Python 3.13 didn't get an alpha1 release. We still have time until October 2024 to refine the documentation, the function name, come with a better API, etc. There is a non-zero risk that we will keep the name and so we will be good :-) |
Sorry, something went wrong.
⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️Hi! The buildbot s390x Fedora Clang Installed 3.x has failed when building commit 64f158e. What do you need to do:
You can take a look at the buildbot page here: https://buildbot.python.org/all/#builders/531/builds/4639 Failed tests:
Failed subtests:
Summary of the results of the build (if available): == Click to see traceback logsTraceback (most recent call last):
File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang-installed/build/target/lib/python3.13/test/test_subprocess.py", line 769, in test_pipesize_default
self.assertEqual(
AssertionError: 65536 != 8192
Traceback (most recent call last):
File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang-installed/build/target/lib/python3.13/test/test_subprocess.py", line 727, in test_pipesizes
p = subprocess.Popen(
^^^^^^^^^^^^^^^^^
File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang-installed/build/target/lib/python3.13/subprocess.py", line 992, in __init__
errread, errwrite) = self._get_handles(stdin, stdout, stderr)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang-installed/build/target/lib/python3.13/subprocess.py", line 1731, in _get_handles
fcntl.fcntl(errwrite, fcntl.F_SETPIPE_SZ, self.pipesize)
PermissionError: [Errno 1] Operation not permitted
|
Sorry, something went wrong.
Py_IsFinalizing()to the limited API/stable ABI #110397📚 Documentation preview 📚: https://cpython-previews--110441.org.readthedocs.build/