On 01/25/10 04:53 PM, [email protected] wrote:
On Mon, Jan 25, 2010 at 04:19:03PM -0600, Shawn Walker wrote:
No, this will not cause all results to be held in memory (simple
tests of generators of generators with print statements show this).
However, after reading section 5.2.8 of python's expressions doc, I
think we're sort of stuck here (see above).
At the moment, there seems to be connectivity problems for networks that
are off SWAN. I'll try to take a look at the expressions doc whenever
we get internet access back.
In the mean time, I think there is a solution, but it has some tradeoffs
that aren't espeically palatable. Instead of returning a generator
function, remote_search should return an object that's iterable. The
object will cache some number of search results, but not so many that
takes up a lot of memory. Iterating over the object will produce the
same results that remote_search() does now, but when the object runs out
of cached results it will have to go to the transport and request more
data to fill its buffer. This object will hold a reference to the API
and will only be cancelable when it's holding the activity lock which is
when it's downloading additional search results.
...
However, I don't see any better approach.
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:
----------8==--------------------------
#!/usr/bin/python2.6
def gen():
for i in (1, 2, 3):
print "gen yielding: %d" % i
yield i
def wrap_two():
try:
for i in gen():
yield i
finally:
print "finally!"
g = wrap_two()
print g.next()
g.close()
print "All values printed."
----------==8--------------------------
gen yielding: 1
1
finally!
All values printed.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
