The question of whether to keep the entire list of patterns in memory is orthogonal to whether a PatternGenerator may return None.  Yes, it's desirable to have a good way to read from a list one at a time without consuming extra memory, and I'm all in favor of having that.   

But unless I'm misunderstanding you, the problem of having the network state wiped out is caused by returning None, *not* caused by the existing assignment.  Isn't that what you are really saying?  I.e., in the current code no PatternGenerator is allowed to return None, and you've now added one that returns None, and found that when it happens the weights get wiped out.  If so, the solution seems to me to be to make sure never to return None, because returning None is *not* allowed and not supported.   So I agree that there is a problem, I agree with the overall goal, but at least with the information I have so far, I don't agree that checking for None in the GeneratorSheet is the appropriate fix, because I don't think None should ever have been allowed to be returned by a PatternGenerator in the first place.   

Maybe the best way forward would be to supply the entire set of code for the example where this occurs, so that I can suggest a more appropriate place to make the fix.  I'm a bit hamstrung right now because I can only see the code on one side, and don't think the fix belongs there, and can't see the part where I think it does belong.  Hope that makes sense!