[Python-Dev] List posting custom [was: current status of discussions] (original) (raw)

Koos Zevenhoven k7hoven at gmail.com
Wed Apr 13 15:59:50 EDT 2016

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 "mypath.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 PyXSETREF. [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.

More information about the Python-Dev mailing list