Re: Argumenting in favor of first()

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*
participants (1)
-
Juancarlo Añez