Home Original page

[Python-Dev] PyGC_Collect ignores state of `enabled`

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)

>> PyImport_Cleanup() 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 PyImport_Cleanup() 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