On 06/29/2020 08:13 AM, Keara Berlin wrote:
Hi all, I didn't mean for there to be significant differences between what I posted here versus in the commit message. Sorry for any confusion around that! Thank you for putting them both in one place here - that is helpful.
To be clear, the proposed change:
"When writing English, ensure that your comments are clear and easily understandable to other English speakers."
And the commit message:
Instead of requiring that comments be written in Strunk & White Standard English, require instead that English-language comments be clear and easily understandable by other English speakers. This accomplishes the same goal without upholding relics of white supremacy. Many native English speakers do not use Standard English as their native dialect, so requiring conformation to Standard English centers whiteness in an inappropriate and unnecessary way, and can alienate and put up barriers for people of color and those whose native dialect of English is not Standard English. This change is a simple way to correct that while maintaining the original intent of the requirement.
I find it difficult to express my horror and outrage with this commit message, but let me try: Picture this scene from a movie I watched a long time ago: towards the end of the US Civil War a small band of deserters approach a large home; only one man, his wife, and their baby are home as the man's father and brothers have left to run errands. The leader of the small band approaches the man and asks for water. The man, happily and cheerfully, obliges and draws a bucket of fresh well water for them. When he turns around to give them the bucket of water, the leader runs him through with his saber (stabs him in his guts all the way to the hilt). That's what it felt like: betrayal. Before the PEP-8 amendment thread I thought Strunk & White was some popular culture reference, and as such I had no interest in it. However, given the brouhaha that ensued I did some digging to discover for myself what it was. Here is what I have found: - it has had at least four editions thus far - it has been modernized as times have changed (the 2000 edition removed the advice to use masculine pronouns whenever possible, and warns that some will find unnecessary masculine usage offensive) - its advice is hotly debated amongst linguists (not surprising) and perhaps the most relevant: - White is the last name of the second author. Of course I don't know if Keara or Guido knew any of this, but it certainly feels to me that the commit message is ostracizing an entire family line because they had the misfortune to have the wrong last name. In fact, it seems like Strunk & White is making changes to be inclusive in its advice -- exactly what I would have thought we wanted on our side ("our side" being the diverse and welcoming side). According to whichever dictionary Google uses, white supremacy is:
noun the belief that white people are superior to those of all other races, especially the black race, and should therefore dominate society.
Does Keara, Guido, or anyone, have any such examples from Strunk & White? Finally, what's wrong with having a standard? Communication, especially in written form, is difficult enough without everyone using whatever style/grammar/colloquialisms happen to suit their fancy at the time. As a silly example: when I started using Python having the first parameter of a class method be `self` irked me, so I used `yo` instead (Spanish word for "I") -- it was shorter, and it tickled my fancy. Two years into using Python and I replaced every instance of `yo` in my libraries to `self`; the cognitive dissonance between my code and everyone else's was an unnecessary distraction. Speaking of unnecessary, I think the change to PEP-8 was unnecessary. I think it was pushed through without any consideration for those against it, and I think the commit message was extremely offensive. To hopefully stave off some attacks against me: - I am not white - I am not Ivy League educated - Black lives do matter - Police are terrifying -- ~Ethan~
On 30 Jun 2020, at 12:44, Ethan Furman <ethan@stoneleaf.us> wrote:
Of course I don't know if Keara or Guido knew any of this, but it certainly feels to me that the commit message is ostracizing an entire family line because they had the misfortune to have the wrong last name. In fact, it seems like Strunk & White is making changes to be inclusive in its advice -- exactly what I would have thought we wanted on our side ("our side" being the diverse and welcoming side).
The claim in the commit message that the Strunk & White style contains relics of white supremacy might be fair or it might be overblown. I don't know, I'm not an expert. Your research on the updated editions and evolving advice looks good. (Just note that the most popular edition for people to find is very old because it's in the public domain.) In any case, saying that Keara and Guido mistook the family name of one of the authors for skin color feels derogatory. The commit message clearly is controversial but when you say the change itself was unnecessary, consider that English is now a language predominantly used outside of USA and Great Britain. Relaxing the recommendation to use S & L Standard English in the CPython codebase isn't problematic in this sense. That recommendation was largely ignored anyway, as core developer voices in the other threads already admitted. So, chaos won't ensue. We still want to maintain consistency, as PEP 8 recommends. I don't think you have to worry now about seeing organization and organisation in the same docstring.
That's what it felt like: betrayal.
This entire section of your message is confusing to me. Mind explaining? How does a commit message equate stabbing somebody who helped you? What is being betrayed in this commit? - Ł
On 06/30/2020 05:03 AM, Łukasz Langa wrote:
My apologies, that was not my intent. As I said, I never knew what it was until today (er, yesterday now).
The commit message clearly is controversial but when you say the change itself was unnecessary, consider that English is now a language predominantly used outside of USA and Great Britain. Relaxing the recommendation to use S & L Standard English in the CPython codebase isn't problematic in this sense. That recommendation was largely ignored anyway, as core developer voices in the other threads already admitted. So, chaos won't ensue. We still want to maintain consistency, as PEP 8 recommends. I don't think you have to worry now about seeing organization and organisation in the same docstring.
Well, that wouldn't bother me -- as often as not I use non-US-English spellings; I just appreciate if it's a correct spelling /somewhere/.
That's what it felt like: betrayal.
This entire section of your message is confusing to me. Mind explaining? How does a commit message equate stabbing somebody who helped you? What is being betrayed in this commit?
The original request for the change had absolutely no hint that the current text was racist in any way; then we find out that, apparently, we've been harboring white supremacist ideals by prescribing when to use apostrophes and commas? That commit message (not the commit itself) took what should have been a simple change and turned into a platform for political grandstanding of the worst kind: - False, as far as I can tell (until given confirming examples from the S&W text) - Only colored people are mentioned (and other /native English speakers/) - Zero mention of non-native English speakers Basically, it feels like we were lied to. And if that wasn't bad enough, to see that Guido accepted that vitriolic commit message and merged it in ... it makes me embarrassed to be a Python supporter. -- ~Ethan~
Only Guido could attest to this, but as someone who spoke in support of the change, I personally missed the commit message until attention was drawn to it in the python-ideas thread. When reviewing PRs, I'll admit that I don't pay a whole lot of attention to the individual commit messages (particularly extended descriptions); most of my attention is on the actual changes made. So, perhaps he did the same? Either way, I don't think I would go as far as to say that it embarrasses me as a Python contributor. That being said, it did very much feel like it went in a completely different direction than the PR description, and I'm uncomfortable with it as well for that reason. So, my vote would be to amend the commit message based on the description of the PR and proposal made in python-ideas. On Tue, Jun 30, 2020 at 8:53 AM Ethan Furman <ethan@stoneleaf.us> wrote:
I didn't want to participate in this discussion, but I will, probably for the following reasons: - I'm French - I bought a copy of Strunk & White during my first trip to the US, in 1990, in a desperate attempt to improve my english writing style. - I can't say it changed my life, but I found the advice it contains useful - and, as noted by others, not just for english speakers. - For this reason, I have some fondness for this book (I know it has its limitations too...). - I'm puzzled by how some people might equate S&W with white supremacy. I was still puzzled, as many others in this thread, until I googled for it, and found some reference to this story: *His former executive assistant, Cassie Jones, who is black, quit shortly after he gave her a gift she considered insulting, three people with knowledge of the matter said.*
*Mr. Lynch said he hadn’t meant to insult Ms. Jones, who declined to comment for this article. “I really only had the intention — like every time I’ve given it before — for it to be a helpful resource, as it has been for me,” he said. “I still use it today. I’m really sorry if she interpreted it that way.”* https://www.nytimes.com/2020/06/13/business/media/conde-nast-racial.html So I guess this gives some context to this discussion. Additional personal remark: I have many times in my professional life given or been given a book about specific work-related topics when I or the other party thought that one could benefit from it in terms of useful work-related skill acquisition. I find it quite hard to understand how someone would reject such a gift and take it as a reason to resign (unless of course there were other things going on in this company, in which case, why bring the focus on S&W ?). S. On Tue, Jun 30, 2020 at 3:29 PM Kyle Stanley <aeros167@gmail.com> wrote:
-- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
So, I think I can explain. (Not with references because I've lost most of them over the years, but bear with me.) The actual advice in The Elements of Style are mostly inoffensive when taken on their own, and out of context. The problem is that the Elements of Style (And many works like it) are built on a system of white supremacy. The grammarian movement, in general, was built on elevating a very specific form of English over others. It specifically was chosen to avoid "lower class" usages and things like AAVE (though that term would not exist for decades after the movement reached a furor). The commentary in the commit message is a plain and simple description of the effects of the grammarian movement to someone who has studied the topic. Strunk & White is just one possible edifice of that history. As mentioned already in this thread, it is not the name of the authors that is the problem, but the movement and history of Standard English that is the edifice of white supremacy. You cannot evaluate the book strictly outside of the context in which it was written and used and declare it's not white supremacist. In summary: The thing being objected to was the idea that we should choose Standard English as our basis for our language guide. Further, S&W, a classical work on how to write Standard English well, is a bad guide when discussing in light of that fact. Each individual who likes Elements of Style is not wrong for liking the book, you can keep it on your shelf and no one will be angry. But this argument about Standard English is propping up a hegemony that affects multiple axes of oppression, and we should be aware of that. Piper Thunstrom My public key is available at https://keybase.io/pathunstrom Public key fingerprint: 8FF9 3F4E C447 55EC 4658 BDCC A57E A7A4 86D2 644F
On Tue, Jun 30, 2020, 10:38 AM Piper Thunstrom
I don't think this is the place for critical literary theory. I am well aware of the social history of the grammarian movement. But I'm also well aware of the "death of the author", and Roland Barthes, and Jacques Derrida, and of the essential role of active readership in giving meaning to texts like S&W. I think the story told in the commit message is well intentioned and mostly wrong because it commits to a naive logocentrism in it's analysis. But surely this isn't the debate needed on GH logs, nor even on python-dev. All we needed was "Removed specific style guide recommendation" ... The MLA conference is two doors down, and to the left.
On Tue, Jun 30, 2020 at 4:39 PM Piper Thunstrom <pathunstrom@gmail.com> wrote:
No we don't. Who are you to tell others what they should be aware of or what they should fight for? And why should I join your battle that I don't even agree with? Most of us probably had no idea what Elements of Style was before this thread started, and *none* of us has ever attributed any racial meaning to it in the 19 years since PEP-8 was put in place. I still don't attribute any racial meaning to it, despite all the twisted explanations which were given about the correlation with white supremacy, which AFAIK are only shared by you and the person who pushed this PR, who is also a newcomer. If anybody can come up here for the first time, impose their world view on the majority just "because it's oppressive", and do this sort of pandemonium, then we can kiss Python goodbye. It also means there virtually is no end to this in the long run, because anyone can come up with any sort of funny theory in order to tilt the direction of the language and deviate its culture from the outside. -- Giampaolo - gmpy.dev
On Tue, Jun 30, 2020 at 11:36 AM Giampaolo Rodola' <g.rodola@gmail.com> wrote:
It's disheartening as hell to watch a core dev so clearly despise the idea of growing the Python community. You have open contempt of the code of conduct, despite the growing movement of underrepresented minorities stating that codes of conduct make them feel safer in their communities. You openly belittle the contributions of people you view as "newcomers". You uphold that grand tradition of technical people who decide that because they are ignorant to a specific kind of oppression, that oppression doesn't exist. My focus in Python is not specifically the advancement of the language as a language (though I care about that, otherwise why would I be subscribed to this list at all?). My focus and love for Python is as a community. And I care, specifically, that I see three threads that are leaving me breathless and sad for my community. I am imagining the pain and hurt these conversations will cause for people who are not as well positioned and not as comfortable in the community. We are going to lose FUTURE contributors because your vitriol and hate for people who care about oppression as it intersects the Python community. You may very well think that's the optimal way for a language to be. I do not. We must, as a community, examine our prejudices and aim to be welcoming or we're going to see a split in Python much worse than Py2 -> Py3. Piper Thunstrom My public key is available at https://keybase.io/pathunstrom Public key fingerprint: 8FF9 3F4E C447 55EC 4658 BDCC A57E A7A4 86D2 644F
On 30/06/2020 16:54, Piper Thunstrom wrote:
Curiously I am yet to see any acknowledgement that the change itself may be detrimental to neuro-atypical people, of whom there are a fair number in the wider Python community (I've taught a number of them Python, so I know that to be true). I didn't consider the point before Steven and Stephen raised it -- like most people, I don't automatically scan for prejudices except the ones I know I am prone to -- but it does fit with what I know of the Aspergers kids I've met. The fundamental issue is this: your politics are not my politics. Keara's politics are not my politics. I don't know either of you well enough, but I strongly suspect that your politics and Keara's politics are not the same either. That's a perfectly natural state of affairs for human beings. The commit message going with the (mild) relaxation of writing standards is a political statement. I hope there's no argument about that. That sets a precedent. Unless the Steering Committee pronounce otherwise (and I hope they do), it is now OK to publish political statements as part of a commit message, presuming they can be contorted to relevance somehow (and that's usually not hard). I guarantee you won't like some of those message, _but the precedent is being set._ Just because a statement is controversial doesn't mean it can't be accepted. Ultimately, putting political statements in non-political places is divisive. This whole exercise is a demonstration of that divisiveness. That's why I don't think they should be allowed in commit messages, even when I agree with them. And that's why I think the commit message in question should be amended ASAP. -- Rhodri James *-* Kynesim Ltd
To paraphrase the Bible: "For where two or three gather, there is politics with them." Changing the commit message, as it has been merged, is now practically hard and highly unusual. If you use GitHub search, you can find other examples of commit messages that would be rewritten if that was doable without cost: https://github.com/python/cpython/search?q=fuck&type=Commits: such commits would not be merged now I imagine *if it was caught before merging* (of course, the repo was not even in git at the time, so there were no pull requests et cetera at the time...) but would have to stay in if already merged. In this case, as is common I think for most software developers or anyone writing any text: I think the main reason all messages are different: commit, email and PR is because they were written at different times and the writer found better ways of distilling their thought process and also got external input through the email thread. In particular, I think it is common for commit messages to be different from the PR messages (precisely because of this!) and as many has said, and as we should remember, this commit (the actual change) was brought by a volunteer in their own time, and had broad agreement (though not unanimous) on the mailing list, yet now we have ended up having a massive mail thread discussing their particular contribution and I am sure they feel obliged to read all these messages. So let's compare the three: *Commit* "Instead of requiring that comments be written in Strunk & White Standard English, require instead that English-language comments be clear and easily understandable by other English speakers. This accomplishes the same goal without upholding relics of white supremacy. Many native English speakers do not use Standard English as their native dialect, so requiring conformation to Standard English centers whiteness in an inappropriate and unnecessary way, and can alienate and put up barriers for people of color and those whose native dialect of English is not Standard English. This change is a simple way to correct that while maintaining the original intent of the requirement." *Email* "[...] Instead of requiring that comments be written in Strunk & White Standard English, PEP-8 should require instead that English-language comments be clear and easily understandable by other English speakers. This accomplishes the same goal without alienating or putting up barriers for people (especially people of color) whose native dialect of English is not Standard English. This change is a simple way to correct that while maintaining the original intent of the requirement." *Pull Request* "Instead of requiring that comments be written in Strunk & White Standard English, require instead that English-language comments be clear and easily understandable by other English speakers. This accomplishes the same goal without alienating or putting up barriers for people (especially people of color) whose native dialect of English is not Standard English. This change is a simple way to correct that while maintaining the original intent of the requirement. This change also makes the requirement more clear to people who are not familiar with Strunk & White, since for programmers, the main relevant aspect of that standard is "be clear and concise;" simply saying that instead of referencing Strunk & White communicates this more effectively." Clearly, the last sentence (starting "This change also") was added after the email thread, *however* note the commit (message) was written before that discussion took place or the PR was made. I think all three texts (barring the addition in the third one) have the same spirit because - "a person of color" is anybody who is not Caucasian/white according to the definition as I understand it and so does Wikipedia: https://en.wikipedia.org/wiki/Person_of_color - "white supremacy" has the academic definition similar to/being "white privilege": https://en.wikipedia.org/wiki/White_supremacy and that's how I read it here, not an ideology, especially given the context and so I think working against alienation of "persons of colors" is aligned/has a similar meaning to with reducing [the relics of] "white privilege" [in not being alienated in terms of language expected in Python comments] and are similarly "political" (I would say "inclusive" and "uncontroversial", but to each their own). I think if you think any one of these 3 is "political", they all are, so to fall over the commit message in particular (because it says "white supremacy"?) seems inconsistent to me. All 3 texts to me are not political, or at least not political beyond what has already been decided: inclusivity in language is explicit in the CoC: "Using welcoming and inclusive language. We're accepting of all who wish to take part in our activities, fostering an environment where anyone can participate and everyone can make a difference." You might disagree whether that should be in the Code of Conduct or whether it was correctly applied here, however there is no disagreeing that the contributor was upfront and honest about the reason why they wanted this change. To call this a "betrayal" as Ethan did seems to imply that the contributor hid their reasoning, but they never did. In Ethan's example, it is more like the leader of the small band asked for some water for his men because they are thirsty and then the leader has a drink as well from the water given: technically he is not one of "his men", but it does not change the nature of the request nor would it change the response to the request. On Tue, 30 Jun 2020 at 18:57, Rhodri James <rhodri@kynesim.co.uk> wrote:
On Tue, 30 Jun 2020, 17:36 Piper Thunstrom, <pathunstrom@gmail.com> wrote: It specifically
I mean, surely not only did it exclude "lower class" terms and AAVE (African American vernacular English, for the rest who don't do well with acronyms) it also excluded a number of dialects used by groups of all colours and backgrounds. I don't think I'd find any Australian words in there nor any Scottish ones, would I? I don't see how standard English is a white supremacist construct. I see it as an intersection of most of the dialects around, as a means to optimize communication by following a common set of guidelines. Can you elaborate on why you view this as being white supremacy?
On 6/30/20 12:18 PM, Jim F.Hilliard wrote:
I agree with this, and for one very good reason, old, staid, sooty and stuffy language has a very big advantage for communicating, and that is being what it is, it tends to change slowly and people are likely to be able to understand it. Local vernaculars, almost by definition change much more rapidly and aren't as wide spread, so it is much more likely that there are many terms and constructions in them will be not well understood (if understood at all) without having to do a lot of research, and even then you may need to figure out which meaning was meant. If your goal is to communicate, going to the old core is usually the best. -- Richard Damon
The grammarian movement, in general, was built on elevating a very specific form of English over others.
Hmm, I'm curious: which form of English do you propose Python should standardize on? I agree that for code comments it may not matter much, but it probably does for documentation. There are people who routinely make small edits to the docs, and they probably do with some kind of standard in mind (even if it's not "S&W"). Is the intent of the change simply to stop saying "we're following rules told by grammarians"... but to still follow them, just without saying so because it makes us feel better? I'm also unclear how the very brand of English you're using is different from the "white supremacist" brand of English that "is propping up a hegemony that affects multiple axes of oppression". Perhaps that's because I'm a non-native English speaker. Regards Antoine.
On 30/06/2020 17:42, Antoine Pitrou wrote:
I suggest Geordie or Glaswegian on the grounds that most people outside of the UK have probably never heard of them hence they should be regarded as neutral in any world wide debate on English. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On 30/06/2020 18:02, Mark Lawrence wrote:
Possibly not. I do recall an occasion when a Glaswegian and a Texan (I think, he was from somewhere Deep South) tried to communicate. They had to get a passing Dutchman to translate for them. (No joke, that really happened.) -- Rhodri James *-* Kynesim Ltd
Which people in the Python community are entitled to say that they find a commit message to be offensive and have that claim treated seriously, compassionately, and as a good reason for accommodative action? Under what circumstances is the appropriate response of the community a dismissive "you are wrong to take offense"? Under what circumstances should a commit message include or imply a contestable, politically charged historical narrative? Some concrete guidelines might be helpful in this conversation. Alan Isaac (just a long-time Python user, who will not post again)
Sorry for fanning the flames, but this whole thread is so over the top I'm finding it kind of entertaining. On 1/07/20 2:23 am, Piper Thunstrom wrote:
This argument seems to rest on the assumption that "lower class" equates to "non-white". This is an extremely US-centric idea. It could possibly even be described as exhibiting a "breathtaking level of ignorance"...
If that's true, then the entirety of Western culture is built on a system of white supremacy. That includes all our modern technology. It includes the Python programming language. We'd better stop recommending Python to people!
Okay, I'm confused. S&W is a symbol of white supremacy that shall never be recommended or mentioned in polite company, but it's all right to have one on your shelf, as long as you keep it to yourself... or something? You can't have it both ways. -- Greg
I agree with you it is over the top, but let's enjoy the popcorn together! On Wed, 1 Jul 2020 at 01:35, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
I kind of of agree with your (attempt) at reductio ad absurdum: Python and Western culture is built on a system of white supremacy (read: white privilege, academic definition of the word), and if we were not trying to fix this (by changes like the one in this commit, or the PSFs stance on inclusivity in the CoC and active work towards this) I would probably actually recommend people to stop using Python: I have stopped watching content because I do not agree with the stances taken by its creator, even when it has not directly affected the content (insofar as I can tell). To take your argument itself to the extreme and Godwin myself, if a neonazi group developped an amazing programming language that had a swastika for its symbol and was littered with references to the Nazis and their ideology, would you recommend it?
What I think was meant here: S&W is inappropriate to use as a community guideline for a diverse community like Python because it is not inclusive and forces (a particular version of) "Standard English" on others, however, you using it for your own writing (while not imposing it on others) is not an issue. As an analogy, in the US it is illegal (as determined by the Supreme Court) for state officials to compose an official school prayer and require its recitation in school, even when those who wish can excuse themselves from reciting it, on the other hand, if a state official composed an official before-school prayer but that was not required to be recited in school, this would be legal and it would be fine for a parent to frame it, display it and have their child pray it before leaving for school: it would then even be ok for the kid to tell the others and their teacher that that's what they do at home!
On Thu, 2 Jul 2020 01:40:56 +0100 Henk-Jaap Wagenaar <wagenaarhenkjaap@gmail.com> wrote:
We're not talking about posting "your own writing", we're talking about comments (and presumably documentation) in a collective software project. There's a need for consistency, however it's specified and achieved. Otherwise why stop at English? I could just as well write my comments in French if it's all about individual freedom. Requiring English is not inclusive, it forced people like me to painfully adapt to a language I wasn't used to. And that has nothing to do with "white supremacy". Regards Antoine.
On Thu, Jul 2, 2020 at 7:27 PM Antoine Pitrou <solipsis@pitrou.net> wrote:
True, but "inclusive" isn't just about the people *writing*. If you write your comments in French, and someone else uses Turkish, another uses Japanese, and still another opts for Hebrew, it becomes nearly impossible for anyone to *read* those comments. Standardizing on a single language ensures that everyone can read the comments in a single, consistent language. If we want to be completely fair to everyone, we could insist that comments be written in Latin. That way, nobody gets a "home turf" advantage, and we're all going to the effort of translation... but I'm sure you agree that this wouldn't be an improvement to Python :) So if there's going to be one language chosen, logically it should be a language that is familiar to many people. That means that Mandarin Chinese, Spanish, and English, I believe, would be the most favoured choices. Chinese has the toughest demands on input methods, and between Spanish and English, I'd need to hear from someone whose first language is Spanish as to how viable it would be. But it's still necessary to standardize on just one. ChrisA
On Thu, 2 Jul 2020 19:38:28 +1000 Chris Angelico <rosuav@gmail.com> wrote:
That was precisely my point. But "language" doesn't stop at the broad category "English" or "French", there are variations thereof, and that's why there can be more precise recommendations to ensure standardizing on a common variant of (for example) "English". Let's say someone write Python comments or documentation in "William Faulkner English" or "James Joyce English". It's gonna be very difficult to read for people like me. Regards Antoine.
On 2/07/20 10:53 pm, MRAB wrote:
Alternatively, it could be an auxiliary language like Esperanto.
Maybe Esperanto in particular wouldn't be the best choice -- I gather it's rather European-oriented. Maybe we should standardise on Klingon? Humans of all cultures would find it equally difficult. -- Greg
On Thu, Jul 2, 2020 at 6:40 PM Chris Angelico <rosuav@gmail.com> wrote:
Thank you for mentioning Japanese. I totally agree with you. Readability counts, not writability. I am not good at English. I can not live in English world. I don't understand many proverbs and idioms. I may not be able to buy even food! But I can read technical documents like RFC. English used in RFC is very clear to me. I don't know English in RFC is S&W English or not. But I believe English used in RFC is very inclusive for the engineers in the world. I don't think I can write such clear English without help. But having such a goal is inclusive for non native English readers. Regards, -- Inada Naoki <songofacandy@gmail.com>
On 02/07/2020 15:25, Inada Naoki wrote:
I wouldn't be so certain. You have an advantage over native English speakers in that you don't use idiomatic cultural references, so you will tend to write clearly and with common vocabulary. Just as Strunk and White would advise :-) -- Rhodri James *-* Kynesim Ltd
Inado-san makes a very good point. The (English) language used in technical documents is not AAVE. It's not Scotts-English. It's not Jamaican vernacular. It's not Indian English. But it is ALSO not American upper-middle class, white ivy-league English. Technical documentation is a kind of DSL within the world of English dialects. There is a greatly restricted vocabulary and grammar used for this purpose, and no native speaker or writer doing "ordinary" communication would use this DSL. On Thu, Jul 2, 2020, 10:35 AM Inada Naoki <songofacandy@gmail.com> wrote:
On Thu, Jul 2, 2020, at 05:20, Antoine Pitrou wrote:
Why indeed? Surely there are people somewhere in the world who write their comments in French, or Russian, or Japanese, and also name their variables in those languages, and I would argue there's nothing wrong with that (it certainly seems a lot of wasted effort supporting Unicode in variable names otherwise), they simply don't form a contiguous community with people whose code is in English And that's the core, I think, of the issue. If the dialect someone wishes to write their comments in is mutually intelligible with "standard" (however defined) English there's no real need to enforce a higher degree of conformity beyond that. It can be understood, and that is enough. Whereas, if it is not, then they are effectively a foreign language programming community, and there's no reason to say they shouldn't go their own way any more than for French/Russian/Japanese/etc. The desire to enforce a higher degree of conformity despite the lack of such a need is what has been described by some in this discussion as "white supremacy".
On Thu, 02 Jul 2020 17:58:44 -0400 Random832 <random832@fastmail.com> wrote:
Because we're talking about PEP 8, and PEP 8 intends to cover the code style used when writing code in the *Python standard library*. I don't think other Python core developers would like to read code with comments written in French (or, indeed, in Russian or Japanese or...). We're not talking about third-party projects, which indeed choose whatever style and language suit them. Regards Antoine.
On Thu, Jul 2, 2020, at 18:15, Antoine Pitrou wrote:
ok, first of all, fair enough, but I do think there should be some recognition of the PEP's role in the wider community as a general style guide for all code written in python. second, you've snipped the entire rest of my post rather than engage with it, and the main point I was making is no less relevant to the standard library, so I will repeat it: If the dialect someone wishes to write their comments in is mutually intelligible with "standard" (however defined) English there's no real need to enforce a higher degree of conformity beyond that.
On Thu, 02 Jul 2020 18:54:26 -0400 Random832 <random832@fastmail.com> wrote:
Well, I disagree, at least for documentation where having a consistent writing style (and it's not only language, but the way things are presented, structured, etc.) makes for a much more pleasant and efficient reading experience. It's not only about being understandable in the basic sense, but in making comprehension, navigation and information retrieval easy. Regards Antoine.
----- Original Message -----
Without having followed the discussion (I just read that specific message), and with the danger of sounding arrogant and wrong, how can you equate a commit message with such a strong wording regarding betrayal, especially when the intention seems to be about being more inclusive? Why is that this change, evokes such strong emotions? When something doesn't practically affect you one way or another and the end-result would be to be more open and inclusive as a community I believe it should be welcomed. You might disagree with the premise but that doesn't make the change and the results any less valid. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat
Just want to throw out a counterpoint to the imagined people - as a real person who is not well positioned or comfortable in the community. I've been lurking on the list trying to wrap my head around the CPython process and how I might contribute. I think it makes sense to remove the S&W standard, making it more open and less intimidating. I'm in a cohort that both agrees with the purported goal and disagrees with the execution. It's disappointing that anyone bringing up any counterpoint has to have a disclaimer so they aren't personally attacked, but this seems to be the level of discourse around these topics. I'm not on Twitter for a reason; the commit message is much more suited to that environment. The goal, if it truly was for making a more inclusive community, has not been accomplished. There is an effect - intended or not - making those of us who would rather focus on solving technical problems than having yet another exhausting emotionally charged rhetorical fight feel unwelcome. The personal attacks being thrown around are not helping. If this was a necessary cost of inclusivity - which is the obvious fallback argument - it would be easier to believe the claim that this is entirely devoted to creating a more open and welcoming community. But the goal of opening things up by removing the S&W guideline could've been trivially accomplished without generating any of this drama. It's baffling claim to promote cohesion and throw a partisan diatribe into the commit message.
Mmm. Well, we said what we had to say.
I think this captures the real intentions of the PR. Best, Matt White
On Tue, 30 Jun 2020 at 11:49, Ethan Furman <ethan@stoneleaf.us> wrote:
PEP-8 however does not mention a particular edition and the version that is readily available (in the public domain) does contain this problematic section "to use the masculine pronouns whenever possible" which is not inclusive. Hence, I think we would be better off not mentioning it or failing that, mentioning a particular edition. I think times/language norms for inclusivity have changed a lot since 2000 (two decades), so another style guide that was more recently updated might be better, if we think there should be one mentioned at all. This is the version I found on Gutenberg: http://www.gutenberg.org/files/37134/37134-h/37134-h.htm and the particular problematic section I mentioned is this:
Use he with all the above words, unless the antecedent is or must be
feminine.'
On Thu, 2 Jul 2020 at 14:34, Henk-Jaap Wagenaar <wagenaarhenkjaap@gmail.com> wrote:
PEP-8 however does not mention a particular edition and the version that is readily available (in the public domain) does contain this problematic section "to use the masculine pronouns whenever possible" which is not inclusive.
(This is a genuine question, and I'm terrified of being yelled at for asking it, which gives an idea of the way this thread has gone - but I genuinely do want to know, to try to improve my own writing). What *is* the correct inclusive way to refer to an unidentified person in a technical document, without sacrificing clarity by using convoluted circumlocutions like "he/her/they" or over-use of the passive voice? My impression is that commonly accepted language rules and usage are lagging behind, and there's no good answer to this question yet :-( Paul
On Thu, Jul 2, 2020 at 10:01 AM Paul Moore <p.f.moore@gmail.com> wrote:
Paul, this is actually a good question to ask. In general, singular "they" is becoming more popular. It's already used frequently for the singular indeterminate pronoun: "Someone wants to talk to you." "What do they want?" Those who favor prescriptivism will tell you this is improper usage (especially when it goes from an unknown someone to a known someone) but it avoids the strange construction of "he or she" and is more inclusive of diverse genders and is historically how the word was used. (For a fun counter example, the word "you" used to be a plural second person pronoun, but no one today would argue that it makes no sense to use it for an individual.) Piper Thunstrom My public key is available at https://keybase.io/pathunstrom Public key fingerprint: 8FF9 3F4E C447 55EC 4658 BDCC A57E A7A4 86D2 644F
On Thu, Jul 2, 2020, 11:08 AM Piper Thunstrom
The first attested use of singular they in English was in 1375 CE. I'm not sure what time frame Piper uses as the increment for "becoming more popular", but its use has waxed and waned for 650 years. The usage has never been rare during those 650 years, but neither has it ever been predominant. It is a completely reasonable approach, and I would not object to encouraging it in Python documentation. Earlier in my life (30-40 years ago) I tended to use s/he or similar forms. I think that 'they' is more inclusive of gender non-binary people, as well as being much more historically established.
On Thu, 2 Jul 2020 at 16:53, David Mertz <mertz@gnosis.cx> wrote:
I was aware of "they" as an option, so I agree it seems like a reasonable approach.
The usage has never been rare during those 650 years, but neither has it ever been predominant. It is a completely reasonable approach, and I would not object to encouraging it in Python documentation.
Nor would I.
Earlier in my life (30-40 years ago) I tended to use s/he or similar forms. I think that 'they' is more inclusive of gender non-binary people, as well as being much more historically established.
I tend to use "they" relatively often, but I have found in the past that it leads me into certain types of awkward sentences (no, I can't think of an example right now) where using "they" doesn't seem right. Maybe that's because I use "he" myself, and feel fairly uncomfortable when I'm referred to as "they", so that colours my impression - even though I'm writing for (generic) other people, I do tend to think in terms of how my words read if I view then as addressed to me. This is where I feel that "language hasn't caught up". My understanding is that technically "he" takes a dual role in English, as both masculine (technical linguistics gender) 3rd person singular and "indeterminate" 3rd person singular (because English doesn't have an "indeterminate-but-not-neuter" gender - do any other languages?). But technical usage is irrelevant here, as people's feelings and identity are involved and language has to reflect that, not the other way round. Maybe sometime in the future, "they" will be the norm and "he and "she" will sound as archaic as "thou" does today. But until then, I feel that we should all tend to assume that everyone is *trying* to be inclusive, and shape our words as best we can to express and include ideas that maybe we don't personally have the experience to really feel as deeply as others do - that's not so much "privilege" in my view as "limited experience" and I hope people would assume I'd like to understand better and mean no harm, rather than that I'm smugly asserting my own world view as the only one that matters (sadly, I appreciate that some people *do* do that, but I doubt that applies to anyone in the Python community...) Anyway, sermon over - thanks for the information and references everyone. Paul
On 2020-07-02 17:14, Paul Moore wrote:
Indo-European languages tend to have grammatical gender (masculine/feminine/neuter or masculine/feminine), but it's not necessarily related to physical gender. Other languages families might have many categories or 'genders', or just distinguish between animate and inanimate (and those might not necessarily be related to whether something is really animate or inanimate). Having only one 3rd-person singular pronoun is by no means unusual.
On Thu, Jul 2, 2020 at 12:15 PM Paul Moore <p.f.moore@gmail.com> wrote:
English has very few gender inflections at all, especially Modern English (i.e. since 16th century CE). We have pronouns, but "they" has long been used in that "indeterminate-not-inanimate" way since 14th century (different from "it"). "He" has often been used that as well, but really with the implication that a generic person is male. Other languages indeed have more complex grammatical gender. For example, Swahili 'has a complex grammatical gender <https://en.wikipedia.org/wiki/Grammatical_gender> system, but as this does not include a distinction based on natural sex, the term "noun class" is generally used instead of "gender".' -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.
On 2020-07-02 15:19, Piper Thunstrom wrote:
Here's an article on singular 'they': https://public.oed.com/blog/a-brief-history-of-singular-they/ TL;DR: It's not a recent usage; it was OK in 1375.
On Thu, Jul 2, 2020 at 12:16 PM MRAB <python@mrabarnett.plus.com> wrote:
Forgive me for not giving a detailed play by play of 15 years of experience specifically as a writer and editor. Over the last handful of decades, singular "they" has been explicitly taught as inappropriate. My own college writing classes (only 10 years ago now) included this specific piece of advice. In terms of modern English vernacular, singular "they" has been continuously and rigorously treated as inappropriate. Those who prefer singular "they", myself included, point to references very much like yours as evidence that it has a long history of usage. But until only the last few years, the popular style guides explicitly forbade it. I hope that helps you understand. Piper Thunstrom My public key is available at https://keybase.io/pathunstrom Public key fingerprint: 8FF9 3F4E C447 55EC 4658 BDCC A57E A7A4 86D2 644F
On 2020-07-02 17:47, Piper Thunstrom wrote:
It's also like saying that you shouldn't split infinitives ("to boldly go") because Latin doesn't (and can't), or that the copula "be" should be followed the nominative case ("It is I", not "It is me") because that's what Latin does (on the other hand, French says "C'est moi", not "C'est je"). English isn't Latin.
On 02/07/2020 18:12, MRAB wrote:
English isn't Latin.
Bizarre as it may sound, I still occasionally find that hard to remember. My English Language teachers were only really interested in teaching English Literature, and considered grammar to be one of those unfortunate things it was better to hide from students. It was in Latin classes that I learned how sentences are put together, and that's what I default to when I'm not thinking hard enough. -- Rhodri James *-* Kynesim Ltd
On 3/07/20 5:37 am, Rhodri James wrote:
For me it's French -- I learned much more about English grammar while studying French than I ever did from English classes. But French grammar is a lot closer to English than Latin is, so I don't usually suffer from much confusion. :-) -- Greg
MRAB writes:
It's also like saying that you shouldn't split infinitives
Amusingly, Strunk (1918) was perfectly happy with split infinitives, though he noted it centered whiteness. (Obviously he didn't put it that way, more along the lines of "some people will look down on you.") In general, the various editions of that text are far less prescriptive, and far more interested in semantics and avoiding annoying readers than simple rule-following.
On 5/07/20 3:24 am, Stephen J. Turnbull wrote:
Um... what? Are you saying that people who split infinitives are usually black, and the people who look down on them are white? If so, it would seem that Strunk is actually standing up for black people here. (I don't actually believe this has anything to do with race, I'm just trying *to fully understand* your reasoning.) -- Greg
On Sat, Jul 4, 2020 at 5:37 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Whatever he meant, nothing about split infinitives is in my 1918 original copy of Strunk's rules, which is basically a compilation of common-sense ways to not write like a legal paper or dissertation trying to baffle the reviewers into approval. Which, sadly, continues into this day. -Em
Emily Bowman writes:
Whatever he meant, nothing about split infinitives is in my 1918 original copy of Strunk's rules,
I'm not sure what you mean by "copy of rules", but it's mentioned couple of times in the book. I'm referring to this passage, from http://www.gutenberg.org/files/37134/37134-h/37134-h.htm#Page_36 (you'll need to scroll down a ways): Split Infinitive. There is precedent from the fourteenth century downward for interposing an adverb between to and the infinitive which it governs, but the construction is in disfavor and is avoided by nearly all careful writers. The Gutenberg Project version claims to be the same as the 1918 version, except for the differences between typesetting of the time and a very small number of typo corrections. Steve
Greg Ewing writes:
On 5/07/20 3:24 am, Stephen J. Turnbull wrote:
Of course not. Base rates suggest they're mostly white.
and the people who look down on them are white?
Doesn't it pretty much go without saying, that the people who look down on split infinitives are elite (and white), that white people look down on black achievements (despite eating them up in the mass media!), and that white supremacists literally live to look down on black people? There's no necessary relation between your two questions. Correlation, yes, but that doesn't help understanding here.
If so, it would seem that Strunk is actually standing up for black people here.
Indeed. One reason why I didn't and don't support that commit.
(I don't actually believe this has anything to do with race, I'm just trying *to fully understand* your reasoning.)
Aw, shucks, I'm so glad you asked! But this isn't the place. I filed off the obvious PII and put the content of the argument in my blog. First, before we click, let's all top up our beverages. This is not simple. It's complex, maybe even complicated. (That's a Zen-based argument against white supremacy.<wink/>) https://turnbull.sk.tsukuba.ac.jp/Blog/20200706.020926.txt Sincere regards, Steve
On Sun, Jul 5, 2020 at 2:37 PM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
I think that's not true. According to this, English speakers in top several locations are about the following: https://en.wikipedia.org/wiki/List_of_countries_by_English-speaking_populati... United States: 283M India: 125M Pakistan: 108M Nigeria: 79M Philippines: 64M United Kingdom: 60M Germany: 45M US and UK (and Germany) are majority white, but the others are pretty small minorities. So by eyeball, that seems to add up to a good number more black and brown English speakers than white ones. Of course... I confess, I don't have data on infinitive splitting rates in Nigeria versus UK. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.
On Thu, Jul 2, 2020 at 12:58 PM Piper Thunstrom <pathunstrom@gmail.com> wrote:
My college writing class in 1985 or so DID NOT eschew singular they. I've been a professional writer for about 30 years now. I am happy to stipulate that your class in 2010 at some particular college included an instructor saying "don't use singular they" ... but that was not uniform across universities in 2010, probably not even across the entire faculty at your particular school. I'm 55 yo, and I remember 50 years ago hearing the nonsense claim that "singular they" is "bad feminists trying to corrupt the English language." I probably didn't know the 14th century origin of the use until a decade or two later than that, but this identical discussion was already extremely old by the time you were born. In terms of modern English vernacular, singular "they" has been
continuously and rigorously treated as inappropriate.
This is absolutely and categorically false. There have been SOME PEOPLE who didn't like the singular they, starting about 1820. The idea never occurred to anyone during the first 450 years of its use. It has also never been uniform opinion at any point in the last 200 years. But as I say, some text books, and quite possibly your particular instructor at some particular school, was of that opinion. Strunk and White, in current editions, does not hold that position. Those who prefer singular "they", myself included, point to references
very much like yours as evidence that it has a long history of usage.
But until only the last few years, the popular style guides explicitly forbade it.
Again... SOME guides. Except the ones that didn't do this.` -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.
On 07/02/2020 10:19 AM, David Mertz wrote:
On Thu, Jul 2, 2020 at 12:58 PM Piper Thunstrom wrote:
On 07/02/2020 David Mertz wrote:
I personally found "they" difficult to use -- I learned it as a plural, and tend to use "one" as a singular, non gender-specific pronoun. But thanks to both my daughter (who studies 16th and 17th century literature), and online articles, I use it now (it stills feels odd at times). But the text in question said nothing about gender issues -- it was about race issues. Can anyone shed light on that? If there is something I need to learn I would like to learn it. What I can offer in return: Know your audience. If there is a difference between white supremacy and White Supremacy you shouldn't expect a majority of programmers to know it. -- ~Ethan~
On Thu, Jul 2, 2020 at 9:51 PM Ethan Furman <ethan@stoneleaf.us> wrote:
Exactly. The explanation so far has been that it is not S&W that is a relic of white supremacy. The Standard English, which it advocates, is. Explaining how that is would make the commit message sensible, to me at least. (though the fact that the description of the PR differs from the commit message was problematic nonetheless.)
On 02/07/2020 17:47, Piper Thunstrom wrote:
In terms of modern English vernacular, singular "they" has been continuously and rigorously treated as inappropriate.
I think you may be being a tad parochial again. I can think of plenty of English vernaculars that treat singular "they" as perfectly appropriate. I don't like it personally, but I've only ever thought of RP (in my British parochialism) as trying to suppress it with any serious effort. -- Rhodri James *-* Kynesim Ltd
On Thu, Jul 02, 2020 at 12:47:07PM -0400, Piper Thunstrom wrote:
You are oversimplifying the situation. It is mostly American grammarians who rail against it, so please don't impose American cultural experiences and values on the rest of the English-speaking world. In terms of modern English *vernacular* (i.e. common speech), singular- they has never really gone out of fashion despite the protests of some grammarians, not even in the USA. For instance Green (1977) reported that singular-they was the "normal" third-person singular generic pronoun among junior college students, and Meyers (1990) found that 52% of college students used it. (Interestingly, she found that male students used singular-they slightly more often than female students.) https://sci-hub.tw/10.2307/455911 The 1996 edition of "The New Fowler’s Dictionary of Modern English Usage" dismissed objections to singular-they, and observed that it is "passing unnoticed" by standard (British) English speakers and copy editors. Likewise the 1998 edition of "The New Oxford Dictionary of English" used the form in their definitions. https://public.oed.com/blog/a-brief-history-of-singular-they/ Even in the USA, the record has been mixed. For example, President George Bush's 1991 State of the Union Address used it: "If anyone tells you that America's best days are behind her, then they're looking the wrong way." and as far as I can tell, it passed without comment at the time. Garner's Modern American Usage (2003) recommended cautious use of singular-they; the 1993 edition of The Chicago Manual of Style explicitly recommended singular-they, (alas, the following edition backpedalled somewhat, suggesting that it was fine in casual writing but not formal writing). Even Webster's Dictionary Of Common English (1989) described it as "in common standard use". While the popularity of singular-they has certainly waxed and waned over the centuries, it was in common use at least back in the 1970s and 1980s, e.g. see the citations here: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4293036/ -- Steven
On 02/07/2020 14:52, Paul Moore wrote:
It depends a bit on circumstances. Often it's easy to rephrase to use a plural noun ("If users want to be able to frobnicate, they can set ALLOW_FROBNICATION=1..."). If you can't do that, you're basically stuffed. "He or she" is unlovely, all the variations of it that people have come up with over the years are worse, "he" will trigger people prone to seeing overarching patriarchalism, "she" will trigger people prone to seeing overarching feminism, and "they" will trigger people who think it's just wrong :-/ -- Rhodri James *-* Kynesim Ltd
If the writing is less formal (and I think most comments and even most documentation is somewhat informal), you can sometimes just address the reader directly, as "you". For the most formal writing most people will ever encounter, one can use "one" as the singular pronoun of indeterminate gender. Alas, I suspect "one" confuses as many people as a singular "they"; in additional to grammatical confusion ("one *what*?"), the formality itself can be a barrier to students who are feeling overwhelmed. The passive voice also has a tendency to creep in more with use of "one." I'm personally fine with singular they, unless the context is very formal. I personally prefer to remedy that confusion by using a less formal style. The people I've met who had genuine and lasting difficulty with singular "they" even in informal contexts were ... at a stage of life where they were unlikely to take up new hobbies as intricate as programming. -jJ
On 3/07/20 1:52 am, Paul Moore wrote:
I don't know if "lagging behind" is the right term, seeing as there seems to have been a fairly good answer available for about 700 years. From https://en.wikipedia.org/wiki/Singular_they: "The singular they emerged by the 14th century, about a century after plural they. It has been commonly employed in everyday English ever since then and has gained currency in official contexts. Singular they has been criticised since the mid-18th century by prescriptive commentators who consider it an error. Its continued use in modern standard English has become more common and formally accepted with the change toward gender-neutral language, though many style guides continue to describe it as colloquial and less appropriate in formal writing." Personally I'd go with that and tell any prescriptivists who object to go and jump in a bitbucket. -- Greg
On Thu, 2 Jul 2020 14:52:04 +0100 Paul Moore <p.f.moore@gmail.com> wrote:
There's no good answer because "good" depends on the morality of the day, and things that used to be "good enough" are now considered (at least by some and/or in some contexts) to be "evil". And whatever seems good today might well become horrible in two decades. Which, actually, is a good argument to let language lag behind the times, because at least you can ensure some reasonable stability in communication conventions. If you change conventions every decade, how will you read texts from the past? Regards Antoine.
On Thu, 2 Jul 2020 at 16:16, Éric Araujo <eric@netwok.org> wrote:
I do not think that technique is as inclusive as we should aim to be (apologies if I get this wrong in terms of gender v.s. sex): there are those who do not self-identify as either gender or prefer another pronoun (I know some who prefer to be called "they" instead of he or she and do not identify as male or female): hence using (singular) they is simply easiest and unoffensive (in my view).
The biggest problem with this is figuring out when to switch. If you switch within a single example, you will confuse many readers. If you have a series of related examples, people will disagree about when it is reasonable to substitute a new person. Using specific personal names (Alice and Bob are traditional) for each character can help with that, but it is still a problem. And using personal names brings up an cultural issues more directly than "Strunk and White" would. (If Bob and Alice seem neutral to you, would you do a double-take on Kehinde or Oladotun?)
[Paul Moore <p.f.moore@gmail.com>]
I've used singular "they" for years'; if someone truly objects to that, they've kept it to themself. "Authorities" are moving in that direction too; e.g., https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they """ The singular “they” is a generic third-person singular pronoun in English. Use of the singular “they” is endorsed as part of APA Style because it is inclusive of all people and helps writers avoid making assumptions about gender. Although usage of the singular “they” was once discouraged in academic writing, many advocacy groups and publishers have accepted and endorsed it, including Merriam-Webster’s Dictionary. """ Then again, we're talking about humans. There's nothing you can do - or refrain from doing - that won't mortally offend someone :-)
On Thu, 2 Jul 2020 at 14:52, Paul Moore <p.f.moore@gmail.com> wrote:
As others have said and more eloquently, I use and would suggest to use (singular) "they" or rephrase it. Furthermore, I have seen no rationale against "they" that I think holds any water (though of course, now one will surface!) and I have not seen it criticized recently. It seems incredibly common in circles I frequent that when an old document is reviewed every occurence of "he" is simply replaced with "they".
Surely, if the argument is to be as inclusive and easy as possible, British English should be used? Things may have changed, but my impression is that the majority of English-second-language (ESL) speakers learn British English, not American. So maybe that should be the switch, if inclusivity and lowering the bar as much as possible is the ideal? Admittedly, I essentially switch between UK/US/Australian/Eastern European/Geordie/southern US/NZ English/French on a regular basis, so it's not a problem for me (but is something I'm possibly more conscious of than most), nor do I think a huge switch of US to UK spellings achieves much, but the nuances and connotation differences are meaningful. On the whole I agree with fixing on a policy where language style that is clear to the most people is the idea. I'm not sure of the wording that should be used to codify that, but something expressing a preference for clear expression in British English (or whatever dialect), with humility insisted on, and deference to 'the community' as to the clarity of wording. Politics aside, clarity and comprehension for the most is the goal, surely? [is what's already done, more or less with the docs, if I understand correctly?] An issue is that commit messages are uneditable after merge, so something written somewhere suggesting consideration of this would be a good idea, with authors/mergers bearing this in mind, however unusual a change on this basis would be. This would be additional burden on the core dev team, but if commitment is to be made to inclusivity, it might be what's necessary. The potential for inclusion and mentoring of contributors whose skill set is more toward documentation, and others who in future might contribute to CPython code is an added bonus. I've been holding this thought a little while, but since the discussion on English dialects has been raised, I think it's a point worth making. yours, David PS The issue with 'they' tends to be that it doesn't adequately convey singular/plural, as I encountered a *lot* writing Communications/Cultural Studies papers when I was at university/in college (see the dialects...). Other languages (say, French) have plural forms of gendered singular, but not an non-gendered form of either. An non-gendered singular, and gendered plurals in English could be useful, but I don't see either becoming accepted soon. The solution, for what it's worth, tended to be a neutral role noun, eg 'the coder', 'the writer', 'the consumer' - which in some cases has an advantage in clarity over they/he/she vis a vis both added role/verb information and gender neutral singular/pluralisation. ------------------------------ Date: Thu, 2 Jul 2020 11:58:16 +0200 From: Antoine Pitrou <solipsis@pitrou.net> Subject: [Python-Dev] Re: Recent PEP-8 change To: python-dev@python.org Message-ID: <20200702115816.77335477@fsol> Content-Type: text/plain; charset=US-ASCII On Thu, 2 Jul 2020 19:38:28 +1000 Chris Angelico <rosuav@gmail.com> wrote:
That was precisely my point. But "language" doesn't stop at the broad category "English" or "French", there are variations thereof, and that's why there can be more precise recommendations to ensure standardizing on a common variant of (for example) "English". Let's say someone write Python comments or documentation in "William Faulkner English" or "James Joyce English". It's gonna be very difficult to read for people like me. Regards Antoine.
On Thu, Jul 2, 2020 at 1:36 PM David Antonini <toonarmycaptain@hotmail.com> wrote:
Oh surely not! Then we'll be asking what COLOUR to paint the bikeshed! Might as well make it from aluminium if we go down that path. :-) I like the Wikipedia rule about this. Different articles are begun by speakers/writers of different regional stylistic variations. So, for example, one article is started using some Commonwealth spelling variants. Another is started using Standard American English. The Wikipedia rule is basically, "do what it started out as, don't go back and change it, but remain consistent." If the documentation for one particular module/library/source file/etc. starts out one way, just use that regional style.
I don't think so. https://docs.github.com/en/github/committing-changes-to-your-project/changin.... Interactive rebasing is perfectly possible, isn't it. I admit my git-fu isn't that strong, but I've done something that I *think* is the same as this. It's possible I'm missing some distinction between the trees I've modified and the current one, but I don't think so. Let's say someone write Python comments or documentation in "William
Faulkner English" or "James Joyce English". It's gonna be very difficult to read for people like me.
We should.... write all of our... comments... in the style of... Louis-Ferdinand Céline (just the ellipses, not the Fascism part) . -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.
On Fri, Jul 3, 2020 at 4:09 AM David Mertz <mertz@gnosis.cx> wrote:
An issue is that commit messages are uneditable after merge, so something written somewhere suggesting consideration of this would be a good idea, with authors/mergers bearing this in mind, however unusual a change on this basis would be. This would be additional burden on the core dev team, but if commitment is to be made to inclusivity, it might be what's necessary.
I don't think so. https://docs.github.com/en/github/committing-changes-to-your-project/changin.... Interactive rebasing is perfectly possible, isn't it. I admit my git-fu isn't that strong, but I've done something that I *think* is the same as this. It's possible I'm missing some distinction between the trees I've modified and the current one, but I don't think so.
When you do that sort of rewriting, you're constructing a new and independent history and then saying "hey, this is the history I want everyone to respect now, thanks". It's full-on Back To The Future stuff, and can have annoying or serious consequences with everyone who has a clone or fork of the repo. It would be extremely annoying to anyone who has an open PR at the time of the rewrite, but the annoyance would be temporary (hopefully one-off). ChrisA
On Fri, Jul 3, 2020 at 5:17 AM Ivan Pozdeev via Python-Dev <python-dev@python.org> wrote:
I think I agree. The consequences would be notable, but not untenable. There's a lot of debate still, but I think that if the commit message were amended (and the commit diff kept as it currently is), there could be a non-vitriolic discussion about whether or not to include any further stipulations about the quality of English used. (Which might result in no change at all. That's a valid conclusion.) Formal proposal: Either request a new commit message from the original author, or have someone rewrite it, and we go ahead and make the change. ChrisA
Perhaps you could revert the original commit, then apply the same diff again with an adjusted message? Would that strike a good balance? Cheers, Barney On Thu, 2 Jul 2020 at 21:36, Henk-Jaap Wagenaar <wagenaarhenkjaap@gmail.com> wrote:
-1 This would be serious precedent to fiddling with publicly replicated repo history. This would require coordination with project admins as force-pushes are rightfully disabled for our repositories. Commit messages aren't usually scrutinized to this extent. If you looked at the last 1000 commits in cpython, you'd find quite a few with messages that could be seriously improved. We don't though because commits are immutable. You can revert them but we never downright replace them with different ones. Otherwise what's the point in me signing release tags? Is the commit message perfect? No. Is the intent explained better on the linked PR? Yes. Is the change itself good? Also yes. Formal proposal: leave this alone. - Ł
On Thu, Jul 2, 2020 at 8:34 PM Łukasz Langa <lukasz@langa.pl> wrote:
At this point, I agree that everyone should forget about all this. The arguing is pointless, the PEP 8 text is very slightly better than it used to be (or even if you think it's very slightly worse, it's still not a big thing). I also think that this situation is a bit different than the last 1000 commits. Many of those were probably less well phrased or less accurate than they could have been, but in ways that are not contentious in the overall community. A little while ago, I made a one sentence change to PEP 584. Brandt thought it was unnecessary, Guido thought it was worth accepting. It's not *really* important either way. My exciting commit message was "PEP-0584: Specify order guarantee." But if I really wanted to, I probably could have snuck in a paragraph describing my feelings about Zorn's lemma, and inuititionistic set theory, and well-ordered cardinals. If anyone later noticed my comment, they'd think "David is a bit nuts." The message would kinda-sorta relate to the change, but not really; however generally in the Python community the tempers between the Brouwerists and Hilbertists have calmed down in these last 100 years (but lets note that Brouwer was Dutch!). -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.
On Fri, Jul 3, 2020 at 10:10 AM Łukasz Langa <lukasz@langa.pl> wrote:
Commit messages aren't usually scrutinized to this extent. If you looked at the last 1000 commits in cpython, you'd find quite a few with messages that could be seriously improved. We don't though because commits are immutable. You can revert them but we never downright replace them with different ones. Otherwise what's the point in me signing release tags?
True, but very few of them have caused such controversy as this. And I don't believe anyone signs release tags on the PEPs repository (correct me if I'm wrong?), and it has far fewer forks and generally shorter-lived ones than CPython has. I am NOT advocating commit rewriting on CPython itself. ChrisA
On 03.07.2020 3:10, Łukasz Langa wrote:
Per https://mail.python.org/archives/list/python-dev@python.org/message/T7CM4AUJ..., "commits are immutable" is just one point of view, as valid as the other one, and leaving this commit as is would be much more harmful than an average poorly-worded one. Per https://mail.python.org/archives/list/python-dev@python.org/message/KQSHT5RZ..., we're talking about an infinitely less impactful peps repo (per https://mail.python.org/archives/list/python-dev@python.org/message/64LIUO4C..., only 6 people in the entire world would be affected). And, no-one suggested overwriting a Python release, comparing this to that is blowing it way out of proportion.
On Fri, 3 Jul 2020 at 08:50, Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote:
It will not affect only 6 people. That is just the number of people who have forks that we know about and even those who do not have forks but maintain a copy (for whatever reason) of the main branch will be affected: they will have to reset their branch or do some other malarkey to get this new "improved" history. This will be a much bigger group of people and also potentially software solutions that are mirroring the repo for one reason or another. That's one of the prices you pay (or I would say benefit) for having a decentralized version control system: it makes it hard to rewrite (supposedly "improve") history.
On 03.07.2020 15:01, Henk-Jaap Wagenaar wrote:
So what? They'll have to synchronise their history to ours to be able to make a PR. And if they don't, it doesn't matter for us what they do with the data anyway since they are responsible for maintaining it and keeping it relevant if they need to, not us. Plus, since it's the PEPs repo, it's tightly bould to the Python project -- the usefulness of a fork disconnected from it is pretty low.
On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev <vano@mail.mipt.ru> wrote:
So what?
Unnecessary
That is not a very collaborative mindset. Can somebody give an example of when we force-pushed before? Surely there should be a PEP outlining when we force push and how we communicate this to our "consumers" before/when we do so?
Plus, since it's the PEPs repo, it's tightly bould to the Python project -- the usefulness of a fork disconnected from it is pretty low.
It partially serves as documentation for the Python project, so mirroring it and its documentation (in git form or in its presented form) can definitely have a use, for example, if you are an environment that has no internet access (common in secret government work, and I am sure their IT team will be even less pleased that they have to do something by hand and overwrite history!).
On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote:
I fail to see how. We provide all the tools to collaborate. If a person has a divergent history, they will see that when trying to collaborate (submit a PR or otherwise interact with our repo from theirs in any way) and will be able to fix that problem then and there.
On Fri, Jul 3, 2020 at 11:03 PM Ivan Pozdeev via Python-Dev <python-dev@python.org> wrote:
Even if someone isn't aware of the change, the PEPs repo *already* rewrites commits as they get merged, so any discrepancies would be papered over cleanly. Consider: https://github.com/python/peps/pull/1488 Two commits in the pull request https://github.com/python/peps/commit/045450aaf47941f3ee7daaa1774947b31885b2... One commit in the final repo. If someone has the old version of the repo and creates a pull request, we'll just squash all the differences down and create a single commit that does the intent in a cleaner way. The only real effect will be a bit of noise during the PR process itself. There has ALREADY been far more hassle resulting from this commit message than there would be from a force-push. ChrisA
On Fri, 3 Jul 2020 at 14:28, Chris Angelico <rosuav@gmail.com> wrote:
That is not the right way of putting it in my opinion. What you describe below is rewriting commits when merging/completing a pull request (squashing is common). That is very different to going back to a commit that is already in the same branch and rewriting that.
Maybe, but rewriting it would (a) not make the "hassle" go away and (b) would in my view create more "hassle".
On 03/07/2020 01:10, Łukasz Langa wrote:
Commit messages aren't usually scrutinized to this extent.
Commit messages are usually political statements.
Formal proposal: leave this alone.
-1. Simply by having it in the repository, the statement implicitly has the support of the Python community (more specifically the Steering Council). Given the manifest controversy, leaving it alone is... a brave decision, minister[*] [*] See the original UK TV series "Yes, Minister" and "Yes, Prime Minister". The senior civil servant praises his minister for making a "brave decision" when he wants to point out consequences the minister won't like. -- Rhodri James *-* Kynesim Ltd
Specifying British English (as opposed to just British spelling) would probably tempt people to use more Brit-only idioms, in the same way that Monty Python tempts people to make Flying Circus references. I don't love the idea of talking more about how many zeroes in a billion, or whether "table it" is an extra-fun reference *because* of the ambiguity. -jJ
On 2020-07-03 17:52, Jim J. Jewett wrote:
Specifying British English (as opposed to just British spelling) would probably tempt people to use more Brit-only idioms, in the same way that Monty Python tempts people to make Flying Circus references.
I don't love the idea of talking more about how many zeroes in a billion, or whether "table it" is an extra-fun reference *because* of the ambiguity.
The UK officially switched to the "short" billion (9 zeros) in 1974. See: https://en.wikipedia.org/wiki/Billion
On 4/07/20 4:52 am, Jim J. Jewett wrote:
Specifying British English
"British English" is woefully underspecified -- there are probably more variants of English used in Britain than in the rest of the world put together. -- Greg
No contention to the contrary, but as a routine, post-merge git history rewrite, not a grand plan, from what I understand. Oh the other hand, an 'official' comment on the commit, recognising the issue with the original commit message, the following discussion, and any conclusions that get reached, might be better, in my opinion. I prefer to recognise and critique, rather than erase, 'historical' history, as a rule (as opposed to git history). I think similar damage is done in this case, when the record, and opportunity to point to and learn from it, is erased. David --------------------------------------------------- Date: Thu, 2 Jul 2020 21:33:56 +0300 From: Ivan Pozdeev <vano@mail.mipt.ru> Subject: [Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou) To: python-dev@python.org Message-ID: <e1d9900a-6dae-8bfc-ad0f-a1512cfa87ab@mail.mipt.ru> Content-Type: text/plain; charset=utf-8; format=flowed On 02.07.2020 21:20, Chris Angelico wrote:
If you are talking about rewriting the PEP8 commit, it has proven to cause so much damage that this is warranted despite the inconveniences IMO.
At https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge, they say that the argument of whether to allow overwriting history in VCSes stems from two opposing views on what a project's history should be. One is that is shall be a raw, unedited record of events as they happened; the other is that is should be a (polished and adapted for future reading) story of how the project was made. While I'm firmly in camp story (long story short, it makes history much more useful for everything except playing the blame game), in this case, there's a case-specific reason, too. The remarks that stem the controversy have nothing to do with commit's intent in technical terms: clarifying wording that cause misunderstanding. They were simply speculations by the author (and misguided ones at that since Strunk & White are actually names). Leaving this commit as it is will leave no trace of any "comment on the commit" and later discussion to a future onlooker. And as a commit is the official codebase, it will still appear as endorsed by the dev team. There'd be no clue that this is not the "final" thoughts on the matter and there something else, somewhere else, and who knows where. While editing the message to just state facts (clarifying the wording) and omit specuilations, it will still serve its purpose -- while stating the actual, valid, endorsed by the team (since the concensus is that the change itself was useful and should not be reverted but could be improved further, as a separate initiative), clean from speculations intent of the edit. On 02.07.2020 23:17, David Antonini wrote:
Le 3 juil. 2020 à 00:32, Ivan Pozdeev via Python-Dev <python-dev@python.org> a écrit :
At https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge <https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge>, they say that the argument of whether to allow overwriting history in VCSes stems from two opposing views on what a project's history should be. One is that is shall be a raw, unedited record of events as they happened; the other is that is should be a (polished and adapted for future reading) story of how the project was made.
That's for how to add the commit on the master branch, once it’s there you can’t update it without breaking every fork and PR. For all purposes, the history is immutable for example if you look at the v3.9.0b3 tag, it is signed so you know that this is the code that went into the release according to the person that signed the commit. If you changed any parent commit, it would change all childs and the signature would then be invalid which would be an issue.
On 7/2/2020 6:49 PM, Rémi Lapeyre wrote:
But this commit was to the peps repo, which has far fewer commits, one branch, no tags, and only 10 PRs. So while it's still an issue, it's not as big a deal as if we were talking about the cpython repo. I don't know how many forks have been made since the commit in question. Eric
On Thu, Jul 2, 2020 at 7:55 PM Eric V. Smith <eric@trueblade.com> wrote:
I don't know about new forks that are just sitting there, but GitHub has a handy network graph that shows where every fork has diverged from the main repo: https://github.com/python/peps/network If you look to the right of the line down to KeanaBerlin on June 26, it seems that six people have pushed commits to a fork that diverged after that commit (plus one that committed something to an old fork). That is based on the time of the commit to the fork, not when it was merged into the main repo, so it could be fewer, but in any case no more than six people would need to force-push to their fork(s) if a rewrite was done now. Also, some of those forks may have already been the subject of PRs that have been merged, and therefore may be able to be ignored.
On Thu, 2 Jul 2020 at 21:18, David Antonini <toonarmycaptain@hotmail.com> wrote:
No contention to the contrary, but as a routine, post-merge git history rewrite, not a grand plan, from what I understand.
David, When you post, you (or more likely your mail program) somehow adds the name of the author of the post that you are replying to in parentheses after the subject. This breaks threading (at least in the GMail web interface) and is fairly disruptive to following the conversation. Could you try to stop this happening, please, in the interests of keeping things more readable? Thanks, Paul
participants (36)
-
Alan G. Isaac
-
Antoine Pitrou
-
Barney Gale
-
Charalampos Stratakis
-
Chris Angelico
-
David Antonini
-
David Mertz
-
Emily Bowman
-
Eric V. Smith
-
Ethan Furman
-
Giampaolo Rodola'
-
Glenn Linderman
-
Greg Ewing
-
Henk-Jaap Wagenaar
-
Inada Naoki
-
Ivan Pozdeev
-
Jim F.Hilliard
-
Jim J. Jewett
-
Jonathan Goble
-
Keara Berlin
-
Kyle Stanley
-
Mark Lawrence
-
Matt White
-
MRAB
-
Paul Moore
-
Piper Thunstrom
-
Random832
-
Rhodri James
-
Richard Damon
-
Rémi Lapeyre
-
Stephen J. Turnbull
-
Steven D'Aprano
-
Stéfane Fermigier
-
Tim Peters
-
Éric Araujo
-
Łukasz Langa