[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 09:53:30AM -0500, Benjamin Peterson wrote:

> > This is not an argument either for or against adding LZ4, I have no 
> > opinion either way. But it is a reminder that "just get it from PyPI" 
> > represents an extremely privileged position that not all Python users 
> > are capable of taking, and we shouldn't be so blase about abandoning 
> > those who can't to future std lib improvements.
> While I'm sympathetic to users in such situations, I'm not sure how 
> much we can really help them. These are the sorts of users who are 
> likely to still be stuck using Python 2.6.

Not necessarily. They may have approval for the latest approved vendor 
software, but not for third party packages.

Nick has been quiet lately, it would be good to hear from him, because I 
expect Red Hat's corporate userbase will be an informative example. I 
hear Red Hat has now moved to Python 3 for its system Python, so I 
expect that many of their corporate users will be, or will soon be, 
running Python 3.x too.

In any case, it's not the users stuck on 2.6 *now* that I'm so concerned 
about, since as you say there's nothing we can do for them. Its the 
users stuck on 3.9 ten years from now, who are missing out on 
functionality because we keep saying "its easy to get it from PyPI".

(To be clear, this isn't a plea to add everything to the stdlib.)

> Any stdlib improvements we 
> discuss and implement today are easily a decade away from benefiting 
> users in restrictive environments. On that kind of timescale, it's 
> very hard to know what to do, especially since, as Paul says, we don't 
> hear much feedback from such users.

Indeed, it isn't easy to know where to draw the line. That's what makes 
the PyPI argument all the more pernicious: it makes it *seem* easy, 
"just get it from PyPI", because it is easy for we privileged users who 
control the computers we use.

> The model these users are living in is increasingly at odds with how 
> software is written and used these days. Browsers and Rust are updated 
> every month. The node.js world is a frenzy of change. 

The node.js world is hardly the paragon of excellence in software 
development we ought to emulate.

> Are these users' 
> environments running 5 year old browsers? I hope not for security's 
> sake. At some point, languorous corporate environments will have to 
> catch up to how modern software development is done to avoid seriously 
> hampering their employees' effectiveness (and security!).

Arguably, modern software development will have to slow down and stop 
introducing a dozen zero-day exploits every week. (Only half tongue in 

Browsers are at the interface of the most hostile, exposed part of the 
computer ecosystem. Not all software operates in such an exposed 
position, and *stability* remains important for many uses and users.

I don't see that this is really relevant to Python though, not unless 
you're thinking about accelerating the pace of new releases.