[Python-Dev] How far to go with user-friendliness

Stephen J. Turnbull stephen at xemacs.org
Sat Jul 18 06:34:19 CEST 2015

Antoine Pitrou writes:

 > Frankly, this kind of inept discussion,

I think you misunderstand what's going on.  The people who advocate
removal of a gratuitous special case may lack your perspective, but
they're not incompetent to understand it.  Specifically, you have a
senior committer's perspective on practicality.  But that's nothing
that one imbibes with mother's milk, and worse, it's not the same from
project to project.  I applaud Nick's attempts to communicate his
perspective on Pythonic practicality, both for the feature itself and
for changing it "*right* now".

 > [...] is amongst the reasons why I'm stopping contributing to
 > CPython.

We'll miss your code.  But you're only one committer, even if you've
contributed more than the average amount.  On the other hand, Python
needs to *grow* the committer group beyond its current size, and
*some* such discussion is necessary for new committers' advancement to
"benevolent dictator for one PEP" level, which is also a pain point
IMHO.  This particular case is one of the most salient, because it
involves the application of one of the most difficult principles: "but
practicality beats purity".

I note that you are responding to Ethan, who recently had a couple of
useful PEPs approved and implemented, but it is my impression that he
does not yet consider himself a BD1P candidate.[1]  Contributers like
him should be cultivated and encouraged (even if discussion should be
redirected, see below), not stifled, because they are likely to be
involved in Python at a higher level in the future.  BTW, he's not the
only one in that situation (PEP author and/or subproject leader but
not quite willing to step up for BD1P) in this thread.

 > Every maintainer or contributor now has an army of voluntary
 > hair-splitters to bother about,

I think that's something worth improving.  Specifically, I suggest
that, just as Guido occasionally invokes cloture[2] on a thread, other
senior developers do so too, in their "areas of competence".  Those
areas may need some definition, but clearly in this case Michael is
competent to say "all right girls and boys, I heard you, I disagree,
and it's not going to change".  Of course he already did that, which
is enough for seasoned committers.  What I'm suggesting is that he
should add, "so please stop discussing the issue," as Guido does.
That makes the implication explicit to less-experienced participants,
as well as to those who usually know better but are carried away by
the momentum of the discussion<wink />.

It might also be appropriate to offer the option of asking for
rationale on core-mentorship, where people who have volunteered to
help would-be committers hang out.  (I guess that would be expanding
the mission of core-mentorship, though, so it's not a no-brainer.)

Of course this means that developers with "areas of competence" need
to pay more attention to such threads, and some will resist or not be
very good at it.  But if most do it, it should do wonders to improve
the efficiency of discussion and be a net saving of time for them as
well.  It would be nice if a few volunteered for these "how to
Pythonically resolve conflict of principles" discussions on core-
mentorship, too.

As python-ideas is also a list for "business" discussions, cloture
might usefully be applied there, too, although with more caution (more
seniority required for invoking[3] cloture?) since the latitude of
discussion is intentionally wider there.

[1]  With apologies to Ethan.  I don't speak for him, and my
impressions of him have no validity outside of the current context of
a discussion about cultivating developers.

[2]  https://en.wikipedia.org/wiki/Cloture
There are alternative spellings in that article.  I'm suggesting that
if the idea is adopted, one of the traditional spellings and some of
the properties of parliamentary cloture be sanctioned as Pythonic.
Eg, one aspect of cloture in many parliaments is that it can be
proposed by any member.  Here the implementation would be a frustrated
developer who writes to the "responsible committer" and requests that
he check discussion, and issue a ruling that the thread should end
right away.

[3]  N.B. This wording may be obscure or specific to my dialect.  To
me, "invoking cloture" means *imposing an end to discussion*, as
opposed to merely *proposing* to end it by force.  As in fn [1],
anybody can propose to invoke cloture as I see it.

More information about the Python-Dev mailing list