Python 3.5.1 C API, the global available available is not destroyed when delete the module

[dl l]

I understood call PyGC_collect to release object cycles. But in my python
test code, seems there is NO reference cycle on the Simple object in the
python test code. Why needs to call PyGC_Collect() here?

=========================================================

class Simple:
     def __init__( self ):
         print('Simple__init__')
     def __del__( self ):
         print('Simple__del__')

simple = None

def run():
    global simple
    simple = Simple()

if __name__ == '__main__':
	run()
==============================================================


2016-09-21 13:09 GMT+08:00 dieter <dieter at handshake.de>:

> dl l <ldlchina at gmail.com> writes:
> > I found the problem is resolved if call PyGC_Collect() after
> > PyDict_DelItemString(). Is it expected to call PyGC_Collect() here for
> > Python 3.5 which is not needed for Python 3.3?
>
> Usually, Python uses reference counting to determine when an object
> can be deleted (and then reclaims its memory).
> However, reference counting cannot determine an object's obsoleteness
> when it is involved in a reference cycle. To address most of these
> cases, Python has an alternative way to determine object obsoleteness
> based on marking the accessible objects and garbage collecting
> what is inaccessible. The alternative way is what "PyGC_collect" starts.
>
> If part of the objects where involved in a reference cycle,
> you would have to call "PyGC_collect" also in Python 3.3 in order
> to get a (mostly) clean memory state.
> It might be, that Python 3.5 introduces more cycles than Python 3.3.
> However, more likely, your code was responsible for the cycle creation
> (and not Python itself). Likely, you just did not notice the problem
> back for Python 3.3.
>
> Note that "PyGC_collect", too, is not garanteed to give a memory clean
> state. It does not release object cycles involving objects with
> an explicite destructor ("__del__" method). Those cycles are
> made available to the application (consult the documentation of the
> "gc" module) which can then decide what to do about them
> (e.g. break the cycles and release the associated objects).
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>