[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

Eric Snow added the comment: @chris, I can't promise that anything will happen right away, but I'll be sure to look into this further when I work on improving extension module usage in subinterpreters in the next few months. -- ___ Python tracker

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

Petr Viktorin added the comment: PEP 489 (Multi-phase extension module initialization) makes it possible/easy to unload/reimport extension modules, in the sense of destroying/recreating the module object. The problem is that the modules needs to opt-in to supporting this, which is not

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

chris added the comment: Okay, completely restarting python is not really necessary. Being able to reliably unload and later on re-import python modules (extension modules as well as pure python modules) in an embedded python runtime would solve my problems. One way to achieve that is

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

Change by Christopher Schramm : -- nosy: +cschramm ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

Eric Snow added the comment: Also, PEP 3121 provides a good summary of some of the issues at hand. -- ___ Python tracker ___ ___

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

Eric Snow added the comment: Also, part of the motivation for PEP 489 (extension module initialization) was to help with reloading extension modules. -- nosy: +petr.viktorin ___ Python tracker

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

Eric Snow added the comment: Ah, thanks for clarifying. So which of these is the main thing you really want: 1. reload extension modules 2. completely restart Python It sounds like #1. If that's the case then there are a number of issues to resolve to make it work. However, there are

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

Change by Stefan Behnel : -- nosy: +scoder ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

chris added the comment: Thanks for your comments and the link to the issue from the year 2000. > You mention "embedded python interpreter", but it sounds more like you mean > "embedded python runtime" Yes that's right. Sorry for imprecise wording. > Why is completely resetting Python "a

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

Eric Snow added the comment: Regarding your 3 points: > a) Py_Finalize cannot be used reliably Note that unloading extension modules is not the only thing that Py_Finalize isn't doing that it probably should be. I expect that you would find a number of memory leaks and potentially cases

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

Eric Snow added the comment: The matter of unloading extension modules is partly covered in bpo-401713. However, note that a few things have changed in the last 18 years. :) I think it would be worth revisiting the decision in that issue at this point. If that were sorted out would there

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

New submission from chris : I'm linking an issue from numpy here: https://github.com/numpy/numpy/issues/8097 Embedding python suffers from a possibility to reliably reset the state of the python interpreter. For my use case, I noticed that when using numpy with Py_Initialize() and