[Python-Dev] collections.sortedtree

[Nick Coghlan]

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