[CPyCppyy] Don't use deprecated Py_GetProgramName #16785
Conversation
The `Py_GetProgramName` function in the Python C API was deprecated in Python 3.13 and will be removed in Python 3.15. However, it seems behavior is unchanged by just passing an empty string instead.
Test Results 17 files 17 suites 3d 14h 52m 26s ⏱️ Results for commit 7452d97. |
| // The first element of the PyWideStringList can be arbitray, which | ||
| // you can seen by running the following: | ||
| // | ||
| // Content of test.py | ||
| // ```python | ||
| // print(sys.executable) # will print the executable, e.g. "python" or "root" | ||
| // print(sys.argv) # will print ['test.py', '1', '2', '3'] in this example | ||
| // ``` | ||
| // | ||
| // ```c++ | ||
| // CPyCppyy::ExecScript("test.py", sizeof(argv)/sizeof(argv[0]), argv); | ||
| // ``` | ||
| WideStringListAppendHelper(&fConfig.argv, std::wstring{}.c_str()); |
There was a problem hiding this comment.
Although I trust this is what happens, by reading the docs at https://docs.python.org/3/c-api/init.html#c.Py_GetProgramName it looks to me that the more appropriate string to pass would be fConfig.program_name member
There was a problem hiding this comment.
Oh that's a pretty good idea!
There was a problem hiding this comment.
Actually it doesn't work, because we never set fConfig.program_name. So it's a nullptr, and then there is a segfault down the line.
I think I was simply trying to evolve the existing Python 2 code existing at the time, there is no sophisticated strategy behind. If the usage of the deprecated function can be avoided, great. |
|
Superseeded by #16851. |
The
Py_GetProgramNamefunction in the Python C API was deprecated in Python 3.13 and will be removed in Python 3.15.However, it seems behavior is unchanged by just passing an empty string instead.
This avoids a warning when building CPyCppyy.