[Python-Dev] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c (original) (raw)

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