In the python-ideas thread, "Propagating StopIteration value",
Guido further elaborated "But that just seems to perpetuate the idea that you have, which IMO is wrongheaded. Itertools is for iterators, and all the extra generator features make no sense for it." I agree with this completely.

Given Raymond's consistent rejection of attempts to complexify itertools, I am 90% sure he would reject this also. (If he disagrees, it is easy to re-open.)

You and Serhiy seem to miss that the simplicity of the iterator interface as a lowest common denominator is a feature. It works for its intended purpose. It was fixed in 2.2 and so far not subject to change. And it can effectively be mixed in to other classes to produce iterator + whatever classes. Files are one example -- they are iterators, context managers, and io method objects. Generators, with its additions, are another example of augmented iterator.

"I think it would be useful to chain multiple generators and still get a generator, not an iterator." A generator is an instance of the generator class. As I understand the patch, chain would still produce chain objects, not generator objects, and hence would fail isinstance tests.

I suggested on the thread above that gentools should be a separate module, initially released on pypi. Unless it is easier than I think to produce generator instances in C, it should be coded in Python. That would be good anyway while developing the interface and behavior. Start with your generator chain function.

Perhaps it would help you to understand my viewpoint by considering the analogous statement "I think it would be useful to chain multiple files and still get a file, not an iterator.". Or substitute any other augmented iterator class for 'file'.