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.pet...@gmail.com> wrote: > > > > [Andrew Barnert <abarn...@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-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/ZCESLJFQ5LA3VB6WRPKGJOAU4HEVLQNL/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/3XTDLYX63DRCNTLONNUCSRHXS6OE6APC/ Code of Conduct: http://python.org/psf/codeofconduct/
