Steven D'Aprano writes:
Which of the core devs will have the responsibility for checking that something which is a good-quality, well-maintained, dependable package today remains so a year from now?
All of them and none of them, as usual. Also, since it's not the CPython implementation, I suspect that non-core developers would be given triage privileges here, as they are on the tracker. The more interesting question is how those with privileges will prioritize that task. The answer, it seems to me, is that (a) it will be nowhere near as high as the ideal priority (everything is priority #1!), and (b) it will be surprisingly high to those of us who hate curating other people's work. As far as making this useful and keeping it somewhat correlated with "up to date", I would say maybe apply to PSF (and/or Google SoC et al) to fund bots to check - recent (past year) downloads vs. long term (past five years average) - has any listed maintainer been active on github recently? - who's been active in this package? - how recently has there been activity in this package? - what are the current (say last year) average rates of issue arrival vs average time to fix vs average time to package release containing the fix? and similar statistics. With a little more work (from higher-cost personnel, I suspect) we could get expert opinions on "high-quality" and "well-maintained" and look for correlations with the statistics we can compute from VCS repo activity and PyPI activity.
But I think that anyone who pip installs more-itertools *solely* to avoid copying and pasting the "grouper" receipe from the docs is doing themselves, and the users of their software, a disservice.
Of course, if you have it installed locally, you won't have any invisible garbage Unicode characters or grit-like dumbquotes in your copy-paste source, which is a plus, YMMV. Whether you'd be more likely to remember it's in more-itertools or in xyz.py in an archived workspace of your own the next time you want to use it is a question I don't know the answer to, even for myself.
(Of course the calculus changes if you are a heavy consumer of iterators,
Who isn't? Most of my real problems that are worth writing code for involve iterables, although many are strings or lists or tuples or sets or dicts or views or more specialized containers, not true iterators. But it's helpful if I don't need to care whether it's a sequence or an iterator or some more exotic iterable.
and the extra tools in more-itertools are useful for you.)
That depends on the algorithms you use to process those iterables, of course. In my case for loops, comprehensions, and the occasional generator expression account for the vast majority of iteration, which tends to support your case. On the other hand, sometimes I want something more elegant or performant or I'm not clear that the naive algorithm I think up myself actually handles all the cases I'm going to run into. I really don't think there's much evidence one way or the other about whether in general importing a module for one function is a bad idea, at least when you're programming mostly for personal consumption. And I don't see how "pip install more-itertools" hurts at all, except to make it look like you chose an insanely edgy edge case. It's true that we now know that "grouper" is a three line function, but in many cases the three-line function calls some other function, which might be in yet another module (hopefully in the same package!) In such cases, you may find yourself doing a fair amount of extra work tracking down all the dependencies. Granted, this refactoring may be well worthwhile in the case of a codebase distributed to third parties, but rarely so for personal use. Steve