A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-May/053920.html below:

[Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanupJames Y Knight foom at fuhm.net
Thu May 19 18:36:58 CEST 2005
On May 19, 2005, at 8:43 AM, Phillip J. Eby wrote:
> At 06:09 PM 5/19/2005 +1200, Greg Ewing wrote:
>> Guido van Rossum wrote:
>>> - When a generator is GC'ed, its close() method is called (which  
>>> is a
>>> no-op if it is already closed).
>>
>> Does this mean that all generators will be ineligible
>> for cyclic garbage collection (since they implicitly
>> have something equivalent to a __del__ method)?
>
> No, since it's implemented in C.  (The C equivalent to __del__ does  
> not
> interfere with cyclic GC.)

But you're missing the point -- there's a *reason* that __del__  
interferes with cyclic GC. It doesn't just do it for the heck of it!  
You can't simply have the C delete call into python code...the  
objects the generator has references to may be invalid objects  
already because they've been cleared to break a cycle. If you want to  
execute python code on collection of a generator, it must be done via  
__del__, or else it'll be horribly, horribly broken.

James
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4