[Python-Dev] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c
Tim Peters
tim.peters at gmail.com
Wed Mar 29 02:37:20 CEST 2006
[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 :-)
More information about the Python-Dev
mailing list