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
_______________________________________________
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/DU4IAEDKPSI26GNN54BTTD5RZPXMOW2I/
Code of Conduct: http://python.org/psf/codeofconduct/
