[Andrew Barnert <abarnert@yahoo.com>]
... I think you’re arguing that the philosophy of itertools is just wrong, at least for the kind of code you usually write with it and the kind of people who usually write that code. Is that fair, or am I misrepresenting you here?
It's fair enough, although rather than "wrong" I'd say more that it's inappropriately applying design principles that work well in most of Python's libraries to an area where they don't. The very fact that half the itertools docs are devoted to "recipes" kinda suggests it knows it's leaving its intended audience hanging ;-) It's hardly coincidence that the more-itertools and itertoolz packages are richer, in very similar ways, than Python's version. The primary itertoolz author does a nice job of explaining that project's heritage starting here: https://toolz.readthedocs.io/en/latest/heritage.html
Meanwhile, I think Guido and some others accept the itertools philosophy
Don't know about Guido, but certainly applies to Raymond. Guido is more a practicality-beats-purity guy. but has no natural attraction to functional languages (Raymond partly does, with his APL background). Guido just sees a function here that would be nice to have. I do like functional languages, and always have, so it seems to fall on me here to advocate for what those weirdos value. In part, no, the itertools namespace is not a precious resource that must be vigilantly minimized ;-)
but argue that first needs to be there because many of the kinds of people who need it actually can’t just write it themselves (they don’t know about 2-arg next, or they don’t understand the subtleties of leaking StopIteration, or whatever). That’s a pretty different argument. (Not that there can’t be something to both arguments, of course.)
And I expect Raymond would say `first()` isn't needed at all - if it has to be addressed, make it recipe #30. There's something to that argument too.