On Wed, Apr 13, 2016 at 5:56 AM, Stephen J. Turnbull <step...@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. _______________________________________________ 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
