git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, Nov 29, 2018, at 04:54, Antoine Pitrou wrote:
> On Thu, 29 Nov 2018 09:52:29 +0000
> Paul Moore <p.f.moore at gmail.com> wrote:
> > [This is getting off-topic, so I'll limit my comments to this one email]
> > 
> > On Thu, 29 Nov 2018 at 03:17, Brett Cannon <brett at python.org> wrote:
> > > We have never really had a discussion about how we want to guide the stdlib going forward (e.g. how much does PyPI influence things, focus/theme, etc.). Maybe we should consider finally having that discussion once the governance model is chosen and before we consider adding a new module as things like people's inability to access PyPI come up pretty consistently (e.g. I know Paul Moore also brings this up regularly).  
> > 
> > I'm not sure a formal discussion on this matter will help much - my
> > feeling is that most people have relatively fixed views on how they
> > would like things to go (large stdlib/batteries included vs external
> > modules/PyPI/slim stdlib). The "problem" isn't so much with people
> > having different views (as a group, we're pretty good at achieving
> > workable compromises in the face of differing views) as it is about
> > people forgetting that their experience isn't the only reality, which
> > causes unnecessary frustration in discussions. That's more of a people
> > problem than a technical one.
> 
> I'd like to point the discussion is asymmetric here.
> 
> On the one hand, people who don't have access to PyPI would _really_
> benefit from a larger stdlib with more batteries included.
> 
> On the other hand, people who have access to PyPI _don't_ benefit from
> having a slim stdlib.  There's nothing virtuous or advantageous about
> having _less_ batteries included.  Python doesn't become magically
> faster or more powerful by including less in its standard
> distribution: the best it does is make the distribution slightly
> smaller.
> 
> So there's really one bunch of people arguing for practical benefits,
> and another bunch of people arguing for mostly aesthetical or
> philosophical reasons.

I don't think it's asymmetric. People have raised several practical problems with a large stdlib in this thread. These include:
- The evelopment of stdlib modules slows to the rate of the Python release schedule.
- stdlib modules become a permanent maintenance burden to CPython core developers.
- The blessed status of stdlib modules means that users might use a substandard stdlib modules when a better thirdparty alternative exists.