For the record, more than 80 messages into this thread, I am no longer interested in pursuing this. In any case, this is not the kind of thing Raymond would ever want to see added to itertools. Let's add a recipe for first() to the list of recipes in the itertools docs.

If people want to change itertools' philosophy to add essentially *all* the recipes to the module, putting more-itertools and itertoolz out of business, that's a PEP-worthy undertaking and maybe you can get the new Steering Council behind that.

But (as is no secret) I'm not one of those functionally-minded people, and I don't use itertools much in my own hobby endeavors, so I won't mind much one way or another.

On Tue, Dec 10, 2019 at 9:44 PM Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
On Dec 10, 2019, at 17:12, Tim Peters <tim.peters@gmail.com> wrote:
>
> [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 ;-)

I don’t want to put words in Raymond’s mouth, but I don’t think he thought he was leaving his audience hanging. People will build their own tools out of the toolkit and decide what to share among them, and who knows where it’ll go from there? And where it turned out to go from there is two big, competing, still-evolving collections of tools on PyPI, and itertools even links to one of them, which (at least for me) looks like success.

But I suspect this is exactly what you mean by “principles that work well in most of Python’s libraries”. Haskell doesn’t make you cabal install a hackage to get first. And likewise for Clojure, F#, Scala, etc. (Hell, when you npm install underscorejs, you don’t have to also go install more_underscore as well to actually use it.)

But I think Python is more dependent on its package ecosystem than most of those languages (despite being the one that advertises “batteries included”), and I’m not sure that’s a bad thing here any more than anywhere else. The set of useful things you can build out of the toolkit doesn’t end with the set that come with Clojure.

>> Meanwhile, I think Guido and some others accept the itertools philosophy
>
> Don't know about Guido, but certainly applies to Raymond. 

Well, he probably wouldn’t have written it to that philosophy if he didn’t agree with it. :)

> I do like functional languages, and always have, so it seems to fall
> on me here to advocate for what those weirdos value.

I’m one of those weirdos too. It may be almost an accident that Python turned out to be a great language for lots of functional techniques that other imperative languages didn’t discover until a decade or two later, but it’s a very happy accident.

>  In part, no, the
> itertools namespace is not a precious resource that must be vigilantly
> minimized ;-)

Sure, but it also doesn’t have to be maximized until it reaches parity with Haskell if it works very well (again, at least for me) to let third-party libraries compete to do that. That doesn’t mean it doesn’t ever need to be extended _at all_, but I think the same conservative attitude that works for the rest of Python actually does work fine here. (Although maybe first does meet that conservative standard.)

>> 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.

Yes. I’m not sure I buy it in this case, but I do think it needs to be answered: Why isn’t it sufficient to just add a first recipe (and anyone who follows the link to more-itertools gets it that way)? But I think by this point, we already have at least two answers (yours and Guido’s), it’s just a question of working out whether either one is sufficient for someone to go try to convince Raymond with it.

_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/ZCESLJFQ5LA3VB6WRPKGJOAU4HEVLQNL/
Code of Conduct: http://python.org/psf/codeofconduct/


--
--Guido van Rossum (python.org/~guido)
Pronouns: he/him (why is my pronoun here?)