Sending changed parameters into nested generators

[John O'Hagan]

On Fri, 12 Nov 2010, Ian wrote:
> On Nov 12, 2:47 am, "John O'Hagan" <resea... at johnohagan.com> wrote:
> > I have tried using a deep update function on the original nested
> > dictionary, but this only works if I  change the contents of a list, not
> > if I want to, say, change a node from a list to a dictionary or vice
> > versa, because in that case I'm not operating on the same object the
> > generator is using.
> > 
> > If anyone's still reading :) , how can I send new values to arbitrary
> > sub- generators?
> 
> I think you're focusing too heavily on generators.  Just because a
> nifty language construct exists doesn't mean that it's the right thing
> to use in all situations.  It sounds to me that what you really want
> are objects with .next() methods and externally visible state -- i.e.
> iterators.

Oddly enough I had just begun to replace some of the generator routines in the 
real program with iterator classes, but it didn't occur to me that they could 
solve the nesting problem. I guess I could access the parameters of nested 
iterators like:

MyIter().param.iterator.param

and so on? I'll try it, thanks. Although if it can be done with built-in 
functionality...

> Or it might be that coroutines are what you're really after, although
> I think they would be difficult to manage in the way that you are
> doing.  

From the rather slight docs on these features, it seems they are tailor-made 
for what I'm doing (in fact my exact solution is described there as 
"hackish"!), but so far I can't see how they could solve my nesting problem.
[...]

Thanks,

John