On Mon, Jan 25, 2010 at 05:57:33PM -0600, Shawn Walker wrote: > On 01/25/10 05:51 PM, [email protected] wrote: > >On Mon, Jan 25, 2010 at 05:34:06PM -0600, Shawn Walker wrote: > >>There's one more option. We can require callers to call the new > >>generator close method on the returned generator object (the value > >>returned by a generator initially) and then rely on the finally > >>cause for cleanup: > > > >Thanks. I did see that once I was able to read the documentation. I > >was initially put off on that idea because the itertools functions don't > >invoke a generator's close function. The itertools package assumes that > >all objects are only iterable and just have a next() method. > > This is actually the officially endorsed method as noted via pep > 325, and its replacement (pep 342). So there's a formal mechanism > in place here.
I looked at these PEPs, but I'm not sure how they pertain to itertools? > >Brock observed that as long as we make the calling convention > >explicit, we can probably get away with using close() instead of a more > >complicated approach. The existing callers of remote_search() chain the > >results and iterate through all of them. This will work by default. > >It's only if we get a fancy caller of remote_search() that we'll need to > >worry about the locking issues. If we force those callers to close each > >generator before invoking the next, then that should be sufficient. > > They don't have to explicitly call close() if the generator itself > returns control. Only if they wish to abort generator execution. > Calling close() on the generator actually will throw() a > GeneratorExit exception that the generator can call for the forced > abort case. However, since we actually want the same thing to happen > for a clean finish as for an aborted, relying on finally: seems > reasonable. I meant that if a caller isn't going to iterate through all of the results reutnred by remote_search, then they must call close(). I'm assuming that's what you mean by the generator "returns control?" I think the terminology that's used 5.2.8 is that the generator "exits." I take "returns control" to mean that the yield returned a value to the caller. > I actually wasn't aware of some of the try/finally pitfalls with > generators until today. It's worth noting that python2.4 doesn't > allow a yield statement in a try/finally block, and that there have > been significant improvements in python2.5 and python2.6 for > generators. Indeed. Thanks for pointing me at the relevant PEPs. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
