-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[C API] Deprecate legacy API for configure Python initialization #88279
Comments
The https://docs.python.org/dev/c-api/init.html documentation lists many functions which is the legacy way to configure the Python initialization. These functions are kept for backward compatibility but have flaws and are less reliable than the new PyConfig API (PEP-587) documented at https://docs.python.org/dev/c-api/init_config.html I propose to deprecate the legacy functions to configure the Python initialization. Examples:
I don't propose to schedule the removal of these functions, only mark them as deprecated in the *documentation*. Related issue: bpo-43956 "C-API: Incorrect default value for Py_SetProgramName" and PR 24876. |
PyConfig API was added to Python 3.8, so it's now widely available. Python 3.8 always switched to security fixes only phase. So IMO it's ok to deprecate the old API now. |
""" Well, Py_FrozenMain() should be rewritten with PyConfig, I want to do that for a long time, but I don't know how to test it. It would be nice to have a very basic test for Py_FrozenMain(). See also: |
commit 6cd0446
commit a0ccc40
commit ec7c09b
|
commit 7565586
|
I created bpo-44131: [C API] Add tests on Py_FrozenMain(). |
Thanks for the help Dong-hee ;-) I close the issue, functions are now deprecated. |
Deprecate the following C functions: * PySys_SetArgv() * PySys_SetArgvEx() * PySys_SetPath()
…gvEx (pythonGH-92428) (cherry picked from commit bd030b6) Co-authored-by: Serhiy Storchaka <[email protected]>
…H-92428) (cherry picked from commit bd030b6) Co-authored-by: Serhiy Storchaka <[email protected]>
Python 3.11 deprecates PySys_SetPath and Py_SetProgramName. The PyConfig API replaces these and other functions. This commit uses the PyConfig API to provide equivalent functionality while also preserving support for older versions of Python, i.e. those before Python 3.8. A beta version of Python 3.11 is available in Fedora Rawhide. Both Fedora 35 and Fedora 36 use Python 3.10, while Fedora 34 still used Python 3.9. I've tested these changes on Fedora 34, Fedora 36, and rawhide, though complete testing was not possible on rawhide due to a kernel bug. That being the case, I decided to enable the newer PyConfig API by testing PY_VERSION_HEX against 0x030a0000. This corresponds to Python 3.10. We could try to use the PyConfig API for Python versions as early as 3.8, but I'm reluctant to do this as there may have been PyConfig related bugs in earlier versions which have since been fixed. Recent linux distributions should have support for Python 3.10. This should be more than adequate for testing the new Python initialization code in GDB. Information about the PyConfig API as well as the motivation behind deprecating the old interface can be found at these links: python/cpython#88279 https://peps.python.org/pep-0587/ https://docs.python.org/3.11/c-api/init_config.html The v2 commit also addresses several problems that Simon found in the v1 version. In v1, I had used Py_DontWriteBytecodeFlag in the new initialization code, but Simon pointed out that this global configuration variable will be deprecated in Python 3.12. This version of the patch no longer uses Py_DontWriteBytecodeFlag in the new initialization code. Additionally, both Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag will no longer be used when building GDB against Python 3.10 or higher. While it's true that both of these global configuration variables are deprecated in Python 3.12, it makes sense to disable their use for gdb builds against 3.10 and higher since those are the versions for which the PyConfig API is now being used by GDB. (The PyConfig API includes different mechanisms for making the same settings afforded by use of the soon-to-be deprecated global configuration variables.) Simon also noted that PyConfig_Clear() would not have be called for one of the failure paths. I've fixed that problem and also made the rest of the "bail out" code more direct. In particular, PyConfig_Clear() will always be called, both for success and failure. The v3 patch addresses some rebase conflicts related to module initialization . Commit 3acd9a6 ("Make 'import gdb.events' work") uses PyImport_ExtendInittab instead of PyImport_AppendInittab. That commit also initializes a struct for each module to import. Both the initialization and the call to were moved ahead of the ifdefs to avoid having to replicate (at least some of) the code three times in various portions of the ifdefs. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28668 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29287
Hey there, I'm unsure if this is the right place to ask - if not, please guide me elsewhere. How are projects using the limited python API supposed to port away from the deprecated API? The "new" API in Can you please make this API available through the limited API, or revert the decision to deprecate this API? Thanks |
The proper place is here: #105145 |
I suggest to continue in the dedicated issue: #107954 "No limited C API to customize Python initialization (PyConfig, PEP 587)" I worked on two projects for the limited C API:
So far, I had to put this work aside since I had too many things on my plate. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: