[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). _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/E3CGT57MQAMWSKBNYTXIIPAHQCKFVELZ/ Code of Conduct: http://python.org/psf/codeofconduct/
