Raymond Hettinger added the comment: As soon as the trunk opens again, I'll add Nick's version to the itertools recipes section.
I'm disinclined to add it directly to the itertools module as a native C function for several reasons: * The problem solved isn't that common (very little of code I've ever written or seen would be better-off if this function had been available). The OP's regex use case was shown by Martin to be better written as an explicit for-loop. I think this is probably also true in the general case. * The module unity is about creating iterators. Consumers of iterators such as any(), all(), next(), sum(), min(), max() and others all lie elsewhere. * For-loops are likely to be the one obvious way to do it for other variants such first_false(), first_true_raise_exception_if_not_found(), or first_greater_than_limit(), etc. * For the most part, the functional style of itertool composition has been a win for performance, but not for readabilty. Also, users of the module seem to suffer from having-too-many-choices. Accordingly, I only want to grow the module for cases where there is a clear win. I would have pronounced on this one sooner but was stayed by the enthusiasm of the participants in this thread. David said, "now I have a place in the non-test email code where using this would lead to easier-to-read code". IMO, this is telling. The bar is higher than "I would have used this one time". That doesn't make it worth having to learn and remember. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18652> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
