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

Nick Coghlan ncoghlan at gmail.com
Thu Mar 27 10:58:35 CET 2014

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

On Thu, Mar 27, 2014 at 11:07 AM, Paul Moore <p.f.moore at gmail.com> wrote:

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

And random pieces of C included in the standard library can be shuffled under the carpet under the disguise of upgrade or what are you suggesting?

The sort of thing that happens is that the relevant approvers will accept python-dev as a "trusted supplier" and then Python upgrades are acceptable subject to review of the changes, etc. For a new module, there is a whole other level of questions around how do we trust the person who developed the code, do we need to do a full code review, etc? It's a bit unfair to describe the process as "random pieces of C" being "shuffled under the carpet". (Although there probably are environments where that is uncomfortably close to the truth :-() Paul 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.

As organisations get larger, they have more to lose, so they typically start worrying about that kind of thing. Properly vetting software for licensing and potential security issues is expensive though, so they usually prefer to outsource that task to trusted providers (this is one of the key concepts that gets me paid). Contractual arrangements and brand reputations start to replace blind trust in upstream developers.

Is this less efficient than full open collaboration? Yes, it is - the "verify" part of "trust, but verify" comes at a real cost in time and money. However, there are plenty of good reasons that phrase is "trust, but verify" rather than "trust unconditionally".

You may choose not to care about those more cautious users, and that's fine - but they're still worth taking into account when making design decisions if you want to cross the marketing chasm from "early adopters" to everyone else.

Regards, Nick.

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

More information about the Python-Dev mailing list