[Python-Dev] PyGC_Collect ignores state of enabled (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed May 18 22:11:51 EDT 2016

On 19 May 2016 at 05:04, Ethan Furman <ethan at stoneleaf.us> wrote:

On 05/18/2016 11:52 AM, Neil Schemenauer wrote:

The whole finalize/shutdown logic of the CPython interpreter could badly use some improvement. Currently it is a set of ugly hacks piled on top of each other. Now that we have PEP 3121,

Extension Module Initialization and Finalization https://www.python.org/dev/peps/pep-3121/ we should be able to cleanup this mess.

PEP 3121 is insufficient, since a lot of extension modules can't (or at least haven't) adopted it in practice. https://www.python.org/dev/peps/pep-0489/ has some more background on that (since it was the first step towards tackling the problem in a different way that extension module authors may be more likely to actually adopt)

PyImportCleanup() is the main area of trouble. I don't think we should not be clearing sys.modules and we should certainly not be clearing module dicts.

If there is some whippersnapper out there who wants to get their hands dirty with Python internals, fixing PyImportCleanup() would be a juicy project. Is there an issue filed for it?

It isn't really any one issue, since PyImport_Cleanup aims to tolerate misbehaving modules across multiple Py_Initialize/Finalize cycles within a single process, and hence tries as hard as it can to forcibly break reference cycles and clean up resource allocations.

Switching it over to the suggested PyGC_CollectIfEnabled() API should be fine though - it will just need to be documented that calling Py_Initialize again in the same process is unsupported if you have the GC disabled during a previous call to Py_Finalize.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list