[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 :-) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
