The argument that first(it) and next(it) "look the same" doesn't convince me; if these look the same then all function applications look the same, and that can certainly not have been Meertens' intention. But if everyone thinks that first() should raise, fine, this thread is way too long already (I should have kept it muted :-).
The reason why *first()* must raise is so it can be applied to iterables that may yield *None* as the legit, *first* value. I was after *findall(..)[0]* and other anti-patterns, but, I think that the semantics of *next(it)* cannot be changed to those of *next(iter(it))*, which is what solves most problems, so a new function is needed, one with the semantics of *more_itertools.first()*. As I said elsewhere, maybe it's just a matter of finding the right name, or of admitting that *more_itertools.first()* solved it first. It would be absurd for the docs to provide the source code to *more_itertools.first()* as a recipe, and also absurd to recommend including * more_itertools* in projects (stdlib Python must be self-containing/reliant). Yet! Just agreeing on what the recipe and use-cases in the docs for *itertools* should be would be a great step forward. -- Juancarlo *Añez*