> 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*
_______________________________________________ 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/NKR5CWQ4VM24YTL43H6VJ4B5BPLECDIS/ Code of Conduct: http://python.org/psf/codeofconduct/
