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

[Koos Zevenhoven]

On Wed, Apr 13, 2016 at 5:56 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 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.
>

Thank you for this thoughtful post. While none of the quotes you refer
to are mine, I did try to find whether any of the advice is something
I should learn from. While I didn't find a whole lot (please do
correct me if you think otherwise), it is also valuable to hear these
things from someone more experienced, even just to confirm what I may
have thought or guessed. I can't really tell, but possibly some of the
thoughts are interesting even to people significantly more experienced
than me.

I know you are not interested in discussing this further here, but
I'll add some inexperienced points of view inline below, just in case
someone is interested:

> 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!"
>

That's what I thought too. I remember several times recently that I
have mentioned I agreed about something, then continuing to add more
to it, or even saying I disagree about something else. Part of the
reason to also state that I agree is an attempt to keep the overall
tone more positive. After all, the other person might be a highly
experienced core developer who just did not happen to have gone though
all the same thoughts regarding that specific question recently. I
hope that has not been interpreted as arrogance such as "I know better
than these people".

For me, as one of the (many?) newcomers, especially on -dev, it can
sometimes be difficult to tell whether not getting a reaction means
"Good point, I agree", "I did not understand so I'll just ignore it",
"I don't want to argue with you" or something else. Then again,
someone just saying essentially the same thing without a reference a
few posts later just feels strange. Also, if the only thing people
apparently do is disagree about things, it makes the overall tone of
the discussions at least *seem* very negative. From this point of view
there seems to be some good in positive comments.

> 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.

Personally, I've sometimes feeled the urge to give a positive comment
just to make sure something gets noticed, or to help keep the
discussion *not* go around in circles by pointing out more clearly the
important points to the people not as involved in the topic of
discussion. But I've tried to resist this urge when I don't have
anything to add. I find the notion of S/N (signal-to-noise ratio),
which you in fact brought up recently in another thread, very
important.

>  > 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.