The difficulty is that this new generator of yours doesn't fit with the existing semantics of PatternGenerators.  A PatternGenerator is explicitly defined as an object that, when called, produces a pattern.  Your new one is instead an object that, when called, either produces a pattern OR returns None.  If that's allowed to happen, *every* place a PatternGenerator is used in the code will now have to start checking for None.  That's not a crazy idea, but it has a lot of implications, and I'm not certain it's really a good thing on balance, because it adds a lot of complexity and opens up a lot of potential bugs (because some uses will check for None, and others won't, with problems only arising when someone uses your new PatternGenerator in a new location. 

For your PatternGenerator, is there actually a use case for continuing to run the simulation after the supply of patterns is exhausted? Seems like one could either go back to the starting pattern and begin again, or else one would want the entire simulation to exit once the pattern set has completed.  Just blindly going forward with no patterns (and thus no input events, in your current implementation) doesn't seem like it has any meaning.  So I would assume you'd want to either (a) raise an exception when the pattern set is exhausted (and presumably normally only run in the range before the set is exhausted, or else catch the exception at some other level and deal with it), or (b) re-run the list of patterns automatically. 

If neither of these possibilities covers your use case, then please describe it in more detail, clarifying why a PatternGenerator that returns None is the right solution, and we can see if that makes sense in general. 

Jim

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.