[]Brett Cannon <brett@python.org>]
... Sorry, "needed" was too strong of a word. It's more about justification for including in the stdlib and deciding to support it for a decade or more versus the answer we give for simple one-liners of "put in your personal toolbox if you don't want to type it out every time".
It's slightly tricky to get right. Good enough for me ;-) Note that I coupled this with leaving it in Python too. `itertools` has been quite an inactive module this decade, and looks like it would have enjoyed few commits at all _except_ that it's coded in C. Commits have been mostly due to C fashion changes, like Use PyXXX_GET_SIZE macros rather than Py_SIZE for concrete types. Renamed Py_SETREF to Py_XSETREF _Py_identifier to _Py_IDENTIFIER and various bug fixes due to lack of 100% perfect type checking (& such) at the C level. The support burden for C code is much higher than for Python code.
... Sure, but the question I think that this thread and me are proposing are what "first()" means to everyone. I think you and I are on the same page, but it's a question as to whether others are as well. :)
Except that we're not jumping in cold here. I've been pushing to adopt _exactly_ what more-itertools has done for years already. Steven appears to think `first()` shouldn't exist at all unless it's restricted to container types and spelled in some other way. I'm not sure anyone else has complained about the intended semantics. People always argue about end cases, but more-itertools gave a choice in a simple way: for an exhausted iterator, raise an exception, which can be suppressed by supplying a default to return instead. Nobody has actually argued that it should always - or never - raise an exception in that case. Guido's _implementation_ happened to never raise an exception, but not even he could be bothered to say a word about why that may be _desirable_. And I snipped the rest because it was so relentlessly agreeable ;-)