[Python-Dev] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c

[Phillip J. Eby]

At 06:13 PM 3/28/2006 -0500, Tim Peters wrote:
>2. Because of the obscure gimmicks that try to cater to using old
>     binary extension modules across new Python releases without
>     recompiling, there's no guarantee that the tp_del slot even exists,
>     and therefore we don't try to access tp_del at all unless
>     PyType_HasFeature says the type object was compiled recently
>     enough so that we know tp_del does exist.
>
>When generators grew finalizers, the "Only instances of ... classes
>can have finalizers" part of #1 became wrong, and I expect that's why
>Phillip removed the conditional.  It was the right thing to do from
>that point of view.
>
>I don't understand the #2 gimmicks well enough to guess whether it was
>actually safe to remove all guards before trying to access tp_del (I
>run on Windows, and compiled extensions can never be reused across
>Python minor releases on Windows -- if a problem was introduced here,
>I'll never see it).

By that reasoning, binary compatibility won't be an issue anywhere else, 
either, since the change was made on the 2.5 alpha trunk, and ISTM that 2.5 
will require recompiling extensions anyway.

Now, the trick could potentially be made a bit smarter if there were a slot 
by which gcmodule could ask the object for a finalizer *dynamically*.  A 
generator without an active frame (or an active frame with no "try" blocks 
on the frame's block stack), has no need to run Python code for 
finalization.  Calling tp_clear on such a generator will do anything that 
the actual deletion would, only faster.  :)

So, that approach could be used to get rid of most new leaks caused by 
generator cycles, at the expense of a bit more complexity in the gc and in 
generators.  It won't fix leaks caused by cycles in active generators that 
have active try/finally or try/except blocks, since these are the things 
that actually need finalizing.