[lldb] Fix deprecation warning because of Py_SetPythonHome

[R-Goc]

Currently building lldb with python support causes a deprecation warning in the build. This is caused by the use of Py_SetPythonHome() in ScriptInterpreterPython.cpp:166. Which is deprecated since 3.11. Python is moving to using a different init mechanism, using the PyConfig struct instead, and relying on setting a config string within the struct.
Relevant info:
https://docs.python.org/3/c-api/init.html#c.Py_SetPythonHome
https://docs.python.org/3/c-api/init_config.html#init-config
https://docs.python.org/3/c-api/init_config.html#c.PyConfig
This is a good first issue.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: None (R-Goc)

Currently building lldb with python support causes a deprecation warning in the build. This is caused by the use of Py_SetPythonHome() in [ScriptInterpreterPython.cpp:166. ](https://github.com/llvm/llvm-project/blob/a4ace3de1b390451ce5e41bce74b90dcd992ab61/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp#L145) Which is deprecated since 3.11. Python is moving to using a different init mechanism, using the PyConfig struct instead, and relying on setting a config string within the struct. Relevant info: [https://docs.python.org/3/c-api/init.html#c.Py_SetPythonHome](url) [https://docs.python.org/3/c-api/init_config.html#init-config](url) [https://docs.python.org/3/c-api/init_config.html#c.PyConfig](url) This is a good first issue.

[DavidSpickett]

Thanks for raising this!

This is a good first issue.

It seems like it at first glance but I'm seeing so many #if in the Python init code, I wouldn't recommend it as a good first issue (search for PY_MAJOR_VERSION).

We need to go through that config structure and see if there is anything else there that we set using a different method right now. I guess not because there'd be deprecation warnings for those too, but if we're going to switch to this new config way of doing it, we should move it all.

It's hard to tell what our minimum supported Python even is, we have handling for versions as old as 3.2. So a good first step would be to remove as much of that as we can.

I think 3.6 is our actual minimum given that https://lldb.llvm.org/resources/build.html#optional-dependencies recommends 3.6. Though I doubt that has been updated in a while and I certainly have never built lldb on NetBSD myself. I will get some consensus on what we actually support and improve that document and maybe make cmake check it too.

I see https://docs.python.org/3/c-api/init_config.html#init-config was added in 3.8, so if the change to the config struct is quite large, we might have to #if quite a lot of code. If it's just home we need to set then maybe it's trivial.

Probably not that hard to get it working but enough considerations that would block a beginner I wouldn't recommend it. Though of course anyone can ping me if they want help clearing those blockers.

[R-Goc]

It looks like the whole configuration part of the init api is getting deprecated, and switched over to init_config. I don't see much of it being used. Only

source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp:124:5:    Py_InitializeEx(0);
source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp:128:5:    Py_InitializeEx(0);

So if adding a new initialization I would add it here. (The test suite also uses the old initialization function, but that is not deprecated yet, and probably won't be). Also it would be worth checking if with the new api the initialize threads function needs to be called. Now for newer python versions it only checks for the GIL and handles that.

I'm not sure if the switch should be to initializing a python config (PyConfig_InitPythonConfig()) with signals off (install_signal_handlers) or an isolated python config (PyConfig_InitIsolatedConfig())

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor has already been assigned to this issue. If you believe that no one is actually working on it despite an assignment, ping the person. After one week without a response, the assignee may be changed.
2. In the comments of this issue, request for it to be assigned to you, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: None (R-Goc)

Currently building lldb with python support causes a deprecation warning in the build. This is caused by the use of Py_SetPythonHome() in [ScriptInterpreterPython.cpp:166. ](https://github.com/llvm/llvm-project/blob/a4ace3de1b390451ce5e41bce74b90dcd992ab61/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp#L145) Which is deprecated since 3.11. Python is moving to using a different init mechanism, using the PyConfig struct instead, and relying on setting a config string within the struct. Relevant info: https://docs.python.org/3/c-api/init.html#c.Py_SetPythonHome https://docs.python.org/3/c-api/init_config.html#init-config https://docs.python.org/3/c-api/init_config.html#c.PyConfig This is a good first issue.

[JDevlieghere]

Oops, added the label before reading @DavidSpickett's comment :-)

[JDevlieghere]

I looked at it quickly and I think this shouldn't be too hard to get right if we make Python 3.8 the minimum required Python version (Py_InitializeFromConfig() was added in 3.8). Then we can replace both Py_SetPythonHome Py_InitializeEx and do it all with the new config. Of course we need to keep older versions working too, but they can keep doing what we're doing now.