Le 29/11/2018 à 20:05, Nathaniel Smith a écrit :
On Thu, Nov 29, 2018, 10:32 Antoine Pitrou <email@example.com mailto:firstname.lastname@example.org wrote:
On Thu, 29 Nov 2018 09:49:32 -0800 Nathaniel Smith <email@example.com <mailto:firstname.lastname@example.org>> wrote: > > There are a lot of challenges to switching to a "standard distribution" > model. I'm not certain it's the best option. But what I like about it is > that it could potentially reduce the conflict between what our different > user groups need, instead of playing zero-sum tug-of-war every time this > comes up. There is no conflict between what different _user_ groups need. Including lz4 in the stdlib will not create a conflict for people who prefer numpy or cryptography.
Some users need as much functionality as possible in the standard download. Some users need the best quality, most up to date software. The current stdlib design makes it impossible to serve both sets of users well.
But it doesn't have to. Obviously not every need can be solved by the stdlib, unless every Python package that has at least one current user is put in the stdlib.
So, yes, there's a discussion for each concretely proposed package about whether it's sufficiently useful (and stable etc.) to be put in the stdlib. Every time it's a balancing act, and obviously it's an imperfect decision. That doesn't mean it cannot be done. You'd actually end up having the same discussions if designing a distribution, only the overall bar would probably be lower.
By the way, I'll argue that putting modules in the stdlib does produce better quality modules. For example, putting multiprocessing in the stdlib uncovered many defects that were previously largely unseen (thanks in part to the extended CI that Python runs on). Improving it was a sometimes painful process, but today multiprocessing's quality is far beyond what it was when originally included, and it can be reasonably considered rock-solid within its intended domain.
One argument against putting lz4 in the stdlib is that compression algorithms come by and, unless there's a large use base already, can disappear quickly if they get outdated by some newer and better algorithm. I'm surprised I haven't seen that argument yet.