On 01/25/10 06:14 PM, johan...@sun.com wrote:
On Mon, Jan 25, 2010 at 05:57:33PM -0600, Shawn Walker wrote:
On 01/25/10 05:51 PM, johan...@sun.com 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?
Sorry, I wasn't referring to itertools. I was referring to the use of
close() which doesn't require itertools. You just call close on the
generator reference that is returned.
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
Right.
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.
No, what I meant was the StopIteration case. Or more specifically, when
the generator:
* raises an exception
* executes a return (no arguments)
* yields its last value and finishes iteration (StopIteration?)
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
