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. _______________________________________________ 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