[Guido]
... I do have to admit that I'm probably biased because I didn't recall 2-arg next() myself until it was mentioned in this thread.
I knew about it once, but had forgotten all about it too until this thread :-) Which does indeed make the case stronger for adding itertools.first, even if - unlike me - you're not in favor of adopting more of a "will it be used?" standard for itertools (you don't have to know how functional language folks think to realize that's what such people want - just look, e.g., at the extensive lists of simple-to-implement functions in the Python more_itertools and toolz.itertools packages). Here's another: 2-argument `iter()`. I totally forget about that one at least twice every year ;-) BTW, another change I'd make is to break the tradition of coding every itertools function in C. That makes the implementation bar much higher, and the other similar packages (more_itertools, toolz.itertools) don't bother. There's also that pypy has trouble optimizing code using itertools heavily, _because_ it's written in C instead of Python. But I don't mean to hijack this thread. So just +1 from me for itertools.first (and even if it's implemented as a Python 1-liner).