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

[Tim Peters]

[Phillip J. Eby]
> 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.

I don't know how people work on Linux; that's why I brought it up. 
The binary API version changed to 1013 on the trunk (see
modsupport.h), but that's only "advisory" (it produces a message in
case of mismatch but does not stop the mismatched module from
loading).  For example, I know that Guido has been known not to bother
recompiling when an API mismatch warning is given on Linux.

> 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.

Simpler:  forget generalizing this (YAGNI).  Restore the previous
code, but add a new if-test specific to generators.  Then it will be
bulletproof wrt accessing tp_del, and the generator-specific branch
can be as fast as possible since it _knows_ it's dealing with a
generator.  Generalize it when and only when this bad idea spreads to
other builtin types :-)