Nick Coghlan added the comment: As discussed on python-ideas: the iterator interface is narrower than the generator interface. Tools for working with iterators are *expected* to lose the generator specific details, just as for loops do, especially when they deal with multiple iterators.
When Greg Ewing's PEP 3152 about cofunctions was discussed in the past, the possibility of a C level API to allow other objects to behave like generators was brought up - if such an API is ever adopted, then it *may* make sense to use it in itertools. In the meantime, it's simpler if itertools is consistent about ignoring the .send(), .throw() and return value semantics of generators-as-coroutines. ---------- resolution: -> rejected stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16150> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
