[Python-Dev] Inclusion of lz4 bindings in stdlib?

[Antoine Pitrou]

Le 29/11/2018 à 20:05, Nathaniel Smith a écrit :
> On Thu, Nov 29, 2018, 10:32 Antoine Pitrou <solipsis at pitrou.net
> <mailto:solipsis at pitrou.net> wrote:
> 
>     On Thu, 29 Nov 2018 09:49:32 -0800
>     Nathaniel Smith <njs at pobox.com <mailto:njs at pobox.com>> 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.

Regards

Antoine.