[Python-Dev] collections.sortedtree (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Thu Mar 27 12:10:09 CET 2014

On 27 March 2014 20:38, Chris Angelico <rosuav at gmail.com> wrote:

On Thu, Mar 27, 2014 at 8:58 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 27 March 2014 19:10, Maciej Fijalkowski <fijall at gmail.com> wrote:

I just find "my company is stupid so let's work around it by putting stuff to python standard library" unacceptable argument for python-dev and all the python community.

Due diligence and prudent risk management are not stupid - most open source projects and small companies just don't have the luxury of worrying about them, as they're so far down the list of concerns that the additional risk of using arbitrary code downloaded off the internet doesn't even register. I don't think anyone's saying it's stupid to be cautious, but more that it's stupid to blindly accept the latest python.org release and not accept something from another source. And if that's stupid, well, I'm stupid too - blindly accepting a whole lot of binary package updates because they're on ftp.au.debian.org, for instance. Why do I trust that, and not random sites on the internet? Because I trust that the Debian package maintainers to check what goes through, and I trust that there are people with reputations at stake, who won't want to send something dodgy through. It's not perfect, but it's a whole lot easier than checking every single package that goes through.

Right - trusting the PSF and the Debian package review process are reasonable trade-offs at a personal level. However, it highlights why this is still a benefit of bringing things into the standard library: a lot of the overhead in review and audit processes is incurred based on the number of components to be reviewed, rather than the amount of code they contain. Other aspects of the overhead are incurred per organisation trusted.

Inclusion in the standard library means not only bringing something under the PSF's "trust umbrella", but also within the core Python component. While we usually use corporate environments as our example, it applies equally to Linux distros - they generally have Python packaged already, and will eventually inherit standard library improvements. For third party packages, it requires someone to do the work to get them installed.

Extending our trust to include a new component isn't to be done lightly, but it does genuinely save work in the long run for a whole lot of other people whenever we choose to do so, and that is the point Stephen was making.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list