[Python-Dev] On the necessity of PEPs [was "collections.sortedtree"]

[Nick Coghlan]

On 27 March 2014 12:11, Eli Bendersky <eliben at gmail.com> wrote:
> On Wed, Mar 26, 2014 at 2:27 PM, Benjamin Peterson <benjamin at python.org>
> wrote:
>> I'm not sure if that's a good thing or not.
>
> YMMV but IMHO this is a good thing. PEPs provide a single point of reference
> to a discussion that would otherwise be spread over multiple centi-threads
> (not that PEPs don't create centi-threads, but they outlive them in a way).

>From my point of view, the primary purpose of the PEP process is to
provide a way for us to finally say "yes" to controversial proposals
that have valid arguments against them. When things are obviously good
ideas that don't impose a big maintenance burden, nobody really
objects if we skip the PEP process (that isn't always a good thing -
directory and zipfile execution flew under the radar for years because
it was such a neat idea that Guido approved it directly in the issue,
and then we forgot to mention it in the 2.6 What's New).

Some ideas aren't obviously good, or a suitable API isn't obvious, or
they impose a major additional maintenance burden, or they require a
change to our development policies. In those cases, the PEP process
allows us to collectively ask the question "Is this worth the
hassle?". Cases like the restoration of binary interpolation support,
or my proposal to backport network security features, also showcase
how the PEP process can be used to refine the *question* so the PEP
champion is forced to figure out what they *really* want, and propose
a solution that clearly solves that specific problem, rather than
overreaching and asking for more than is needed. (This is also
reflected in the relative fates of the current matrix multiplication
proposal and previous more general proposals)

With the introduction of the BDFL-Delegate system, and then the
decision last year to give the "Discussions-To" header a bit more
force and allow groups like the Python Packaging Authority to make use
of the PEP process independently of python-dev, the PEP process is
also becoming more streamlined, making it more effective in its role
as a tool for establishing consensus - there's less need to convince
someone to drop a veto without a PEP, as the PEP process itself is
getting less painful.

Most of the time when I hear people say "the PEP process is too
difficult", I eventually find that what they really mean is "learning
the kinds of things that python-dev are likely to be worried about,
and ensuring that the PEP adequately addresses their concerns, and
listening to feedback, and reconsidering what I actually want, and
revising my proposal, such that they eventually say yes is too time
consuming".

Helping people to learn exactly how to navigate that process is
actually one of the main roles of python-ideas these days, although we
don't do a good job (at all) of advertising that fact.

Regards,
Nick.

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