[Python-Dev] List posting custom [was: current status of discussions]

[Stephen J. Turnbull]

The following is my opinion, as will become obvious, but it's based on
over a decade of observing these lists, and other open source
development lists.  In a context where some core developers have
unsubscribed from these lists, and others regularly report muting
threads with a certain air of asperity, I think it's worth the risk of
seeming arrogant to explain some of the customs (which are complex and
subtle) around posting to Python developer lists.  I'm posting
publicly because there are several new developers whose activity and
fresh perspective is very welcome, but harmony *is* being disturbed,
IMO unnecessarily.

This particular post caught my eye, but it's only an example of one of
the most unharmonious posting styles that has become common recently.
Attribution deliberately removed.

 > Sorry for disturbing this thread's harmony.

*sigh*  There is way too much of this on Python-Ideas recently, and
there shouldn't be any on Python-Dev.  So please don't.  Specifically,
disagreement with an apparently developing consensus is fine but
please avoid this:

 > >> Path is an alternative to os.path -- you don't need to use both.
 > 
 > I agree with that quote of Chris.

It's a waste of time to post *what* you agree with.[1]  Decisions are
not taken by vote in this community, except for the color of the
bikeshed, where it is agreed that *what* decision is taken doesn't
matter, but that some decision should be taken expeditiously.[2]
Chris already stated this position clearly and it's not a "color", so
there is no need to reiterate.  It simply wastes others' time to read
it.  (Whether it was a waste of the poster's time is not for me to
comment on.)

What matters to the decision is *why* you agree (or disagree).  If you
think that some of Chris's arguments are bogus (and should be
disregarded) and others are important, that is valuable information.
It's even better if you can shed additional light on the matter
(example below).

Also, expression of agreement is often a prelude to a request for
information.  "I agree with Z's post.  At least, I have never needed
X.  *When* do you need X?  Let's look for a better way than X!"

Unsupported (dis)agreement to statements about "needs" also may be
taken as *rude*, because others may infer your arrogant claim to know
what *they* do or don't need.  Admittedly there's a difficult
distinction here between Chris's *idiom* where "you don't need to"
translates to "In my understanding, it is generally not necessary to",
and your *unsupported* agreement, which in my dialect of English
changes the emphasis to imply you know better than those who disagree
with you and Chris.  And, of course, the position that others are "too
easily offended" is often reasonable, but you should be aware that
there will be an impact on your reputation and ability to influence
development of Python (even if it doesn't come near the point where
a moderator invokes "Code of Conduct").

"Me too" posts aren't entirely forbidden, but I feel that in Python
custom they are most appropriate when voting on bikeshed colors, and
as applause for a *technically* excellent suggestion.  They should be
avoided in the context of value judgments (of "need" and "simplicity",
for example) for the reason given above.

 > When people want to use your library and it requires a string, the
 > can simply use "my_path.path" and everything still works for them
 > when they switch to pathlib.

This is disrespectful in tone.  I don't know if you're responding to
Ethan here, but he's one of the authors in question.  We *know* that
Ethan doesn't like such inelegant idioms -- he said so -- where "this
object has an appropriate conversion to your argument type, so you
should apply it implicitly" is unambiguous.[3] So for him, it's *not*
so simple.  Since it's not a matter of voting, each proponent should
provide more contexts where preferred programming idioms are
"Pythonic" to sway the sense of the community, or if necessary, the
BDFL.

Where that aesthetic came up was in the context of consistently
wrapping arguments that might be Paths in str, as in

    p = Path(*stuff) or defaultstring
    # 500 lines crossing function and module boundaries!
    with open(str(p)) as f:
        process(f)

I think it was Nick who posted agreement with Ethan on the aesthetics
of str-wrapping.  If that were all, he probably wouldn't have posted
(see fn. 1), but he further pointed out that this application of str
is *dangerous* because *everything* in Python can be coerced to str.
That was a very valuable observation, which swayed the list in favor
of "Uh-oh, we can't recommend 'os.method(str(Path))'!"

This is my last post on this particular topic, but I will be happy to
discuss off-list.  (I may discuss further in public on my blog, but
first I have to get a blog. :-)


Footnotes: 
[1]  "You" is generic here.  There are a couple of developers whose
agreement has the status of pronouncement of Pythonicity.  Aspire to
that, but don't assume it -- very few have it, and it's actually
*very* rarely exercised.  And you can recognize them because they are
*asked* to pronounce -- by people whose statements you thought were
already authoritative!

[2]  And even so votes are often overturned by later arguments, both
theoretical and based in experience.  See for example the several
threads over time on the naming of Py_XSETREF.

[3]  Interpreting Zen koans frequently requires figure-ground
inversion.  In this case we can apply "In the face of ambiguity,
refuse to guess" in the form "in the absence of ambiguity, don't wait
to be asked".  I'm hardly authoritative, but FWIW :-) I think Ethan's
esthetic sense here accords with Pythonicity.