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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com