[Python-Dev] Python Language Summit EuroPython 2010

Maciej Fijalkowski fijall at gmail.com
Thu Jul 22 10:43:28 CEST 2010


On Thu, Jul 22, 2010 at 9:51 AM, Brett Cannon <brett at python.org> wrote:
>
>
> On Wed, Jul 21, 2010 at 16:58, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>> On Wed, 21 Jul 2010 11:42:00 -0400
>> Jesse Noller <jnoller at gmail.com> wrote:
>> > On Wed, Jul 21, 2010 at 11:11 AM, Tim Golden <mail at timgolden.me.uk>
>> > wrote:
>> > [...snip...]
>> > > A messy discussion turned on the question of garbage collection of
>> > > module
>> > > objects, and the order in which finalisers are called if at all,
>> > > especially
>> > > when reference cycles exist. Marc Andre was proposing a __cleanup__
>> > > magic
>> > > function
>> > > for Python modules, which would enable the implementer to define the
>> > > order
>> > > in which resources are released / closed down. This is quite a subtle
>> > > area
>> > > and raised the issue of unfinalised objects in a reference cycle whose
>> > > memory has been freed out from under them but which still exist.
>> > > Martin
>> > > described
>> > > the Java approach where finalisers are called once and then flagged so
>> > > they are not called again even if their object is resurrected. This
>> > > sounded
>> > > like a useful approach for Python but would break code which expected
>> > > to
>> > > be able to resurrect an object during its __del__ method... which is
>> > > not
>> > > expected to account for much code.
>> > >
>> > > Guido pointed out that no-one can be expected to hold enough of the
>> > > complexities
>> > > of this area of Python's implementation in their head, and that an
>> > > implementation
>> > > of some sort would need to be written so that the corner-cases could
>> > > emerge.
>> >
>> > FWIW; I'm currently dealing with a bug in this area w.r.t
>> > multiprocessing and threads and modules we have imported vanishing due
>> > to this issue. I'm interested in hearing more.
>>
>> One common resolution is to not use a __del__ method, but instead a
>> weakref callback which will do the necessary cleanup of a certain set
>> of resources. This is of course not applicable in all situations.
>
> That's an option. I just remember Tim bringing up something about that
> approach that didn't quite work as a complete replacement for __del__.
> Basically the whole setting a module's globals to None was done before gc
> came into the language. Now that it's there it seems that it might work to
> simply let gc clean up the module itself. But this brings in the question of
> how to order calling finalizers. It seemed the room had no specific answer
> other than it might just have to be near random as figuring out a reasonable
> order is hard.

If you have a cycle, there is no other way than breaking it at random, right?

Cheers,
fijal


More information about the Python-Dev mailing list