[Python-Dev] reference leaks, __del__, and annotations

[Phillip J. Eby]

At 12:14 PM 3/31/2006 -0500, Tim Peters wrote:
>[Phillip J. Eby]
> > ...
> > As Tim suggested, it'd be better to have the code be generator-specific, at
> > least for now.  That had actually been my original plan, to make it
> > generator-specific, but I was afraid of breaking encapsulation in the
> > garbage collector by having it know about generators.
>
>It sucks in a way, but so would adding yet another new slot just for
>(at present, and possibly forever) making gc and generators play nicer
>together.  "Practicality beats purity" here.
>
> > But now that Uncle Timmy has blessed the approach, I'll go back and add 
> it in.
> > (On Monday, unless somebody gets to it before me.)
>
>It won't be me:  I wasn't even able to make enough time to understand
>the new generator features at the Python level, let alone the
>implementation.  At PyCon, when Guido showed his slide with a new
>yield-as-expression example, for the rest of his talk I was wondering
>what the heck the example meant <0.3 wink>.

Think of yield as being a sort of IPC operator: it sends a value out of the 
generator, and then replaces it with a "return value" that defaults to None.

On the opposite side of the communication, calling send(value) allows you 
to put a value "into" the generator, and returns the next value from the 
generator.  The existing next() operation is effectively send(None).

So, it's effectively an asymmetric IPC system, using a yield operator and a 
send() method.  On either side, the operation takes a value to give to the 
other side of the communication, and then returns the value that's passed 
"back" by the other side.



that takes an expression, sends it out of the generator, and then brings 
back in a "return value" - sort of like sending some kind of IPC message 
out of the process, and receiving a response.