On 06/30/2020 05:03 AM, Łukasz Langa wrote:

...

On 30 Jun 2020, at 12:44, Ethan Furman mailto: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).

In any case, saying that Keara and Guido mistook the family name of one of the authors for skin color feels derogatory.

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~

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

*In November, after she had spent four months working for him, Mr. Lynch called Ms. Jones into his office and handed her “The Elements of Style,” a guide to standard English usage by William Strunk Jr. and E.B. White. Mr. Lynch said he thought she could benefit from it.*

*With its suggestion that her own language skills were lacking, the gift struck Ms. Jones as a microaggression, the people said. A few days later, she quit. Before leaving the headquarters at 1 World Trade in Lower Manhattan, she placed the book on his desk.*

*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 wrote:

...

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.

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 wrote:

...

On 06/30/2020 05:03 AM, Łukasz Langa wrote:

...

...

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

In any case, saying that Keara and Guido mistook the family name of one of the authors for skin color feels derogatory.

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~ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/T55AGV7X... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DOM5V5QS... Code of Conduct: http://python.org/psf/codeofconduct/

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

On Tue, Jun 30, 2020, 10:38 AM Piper Thunstrom

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

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 wrote:

...

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

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.

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

Mmm. Well, we said what we had to say. I think we both agree there's no point in continuing. ;-) Cheers. On Tue, Jun 30, 2020 at 5:54 PM Piper Thunstrom wrote:

On Tue, Jun 30, 2020 at 11:36 AM Giampaolo Rodola' 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

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

-- Giampaolo - gmpy.dev

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 wrote:

On 30/06/2020 16:54, Piper Thunstrom wrote:

...

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.

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.

On 6/30/20 12:18 PM, Jim F.Hilliard wrote:

On Tue, 30 Jun 2020, 17:36 Piper Thunstrom, mailto:pathunstrom@gmail.com> wrote: 

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

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? 

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

On 30/06/2020 17:42, Antoine Pitrou wrote:

Hmm, I'm curious: which form of English do you propose Python should standardize on? Regards

Antoine.

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

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:

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

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

the Elements of Style (And many works like it) are built on a system of white supremacy.

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!

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.

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 wrote:

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:

...

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

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

...

the Elements of Style (And many works like it) are built on a system of white supremacy.

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!

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?

...

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.

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.

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!

-- Greg _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MQK33M4F... Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, Jul 2, 2020 at 7:27 PM Antoine Pitrou wrote:

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

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 2020-07-02 10:38, Chris Angelico wrote:

On Thu, Jul 2, 2020 at 7:27 PM Antoine Pitrou wrote:

...

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

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.

Alternatively, it could be an auxiliary language like Esperanto.

On 2020-07-02 12:32, Greg Ewing wrote:

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.

There are quite a few other constructed languages that you could use, but Esperanto is by far the most successful of them, which is why I mentioned it.

On 02/07/2020 15:25, Inada Naoki wrote:

I don't think I can write such clear English without help. But having such a goal is inclusive for non native English readers.

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

On Thu, Jul 2, 2020, at 05:20, Antoine Pitrou 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".

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, Jul 2, 2020, at 18:15, Antoine Pitrou wrote:

On Thu, 02 Jul 2020 17:58:44 -0400 Random832 wrote:

...

Why indeed?

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

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, Jul 2, 2020 at 10:01 AM Paul Moore wrote:

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

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, 2 Jul 2020 at 16:53, David Mertz wrote:

On Thu, Jul 2, 2020, 11:08 AM Piper Thunstrom

...

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:

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.

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 Thu, Jul 2, 2020 at 12:15 PM Paul Moore wrote:

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

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:

On Thu, Jul 2, 2020 at 10:01 AM Paul Moore wrote:

...

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

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

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 2020-07-02 17:47, Piper Thunstrom wrote:

On Thu, Jul 2, 2020 at 12:16 PM MRAB 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.

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.

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 3/07/20 5:37 am, Rhodri James wrote:

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.

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

On 5/07/20 3:24 am, Stephen J. Turnbull wrote:

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

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

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

On Sun, Jul 5, 2020 at 2:37 PM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:

...

Are you saying that people who split infinitives are usually black,

Of course not. Base rates suggest they're mostly white.

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 wrote:

...

TL;DR: It's not a recent usage; it was OK in 1375.

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.

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:

...

...

TL;DR: It's not a recent usage; it was OK in 1375.

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.

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.

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 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 02/07/2020 14:52, Paul Moore wrote:

On Thu, 2 Jul 2020 at 14:34, Henk-Jaap Wagenaar 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 :-(

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

On 3/07/20 1:52 am, Paul Moore wrote:

What *is* the correct inclusive way to refer to an unidentified person in a technical document... My impression is that commonly accepted language rules and usage are lagging behind,

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

Le 2020-07-02 à 09 h 52, Paul Moore a écrit :

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?

One technique is alternating genders for the imagined user or developer. Otherwise the singular they is the easiest way. Regards

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?)

Greg Ewing writes:

On 4/07/20 4:33 am, Jim J. Jewett wrote:

...

If Bob and Alice seem neutral to you, would you do a double-take on Kehinde or Oladotun?

Maybe we should use randomly generated names for hypothetical persons?

Randomly generated according to what character repertoire and lexical rules (I'm not talking about British v. American)?

On 2020-07-04 05:51, Greg Ewing wrote:

On 4/07/20 4:33 am, Jim J. Jewett wrote:

...

If Bob and Alice seem neutral to you, would you do a double-take on Kehinde or Oladotun?

Maybe we should use randomly generated names for hypothetical persons?

Ideally they should be short names, one or two syllables.

On 2020-07-04 19:23, Paul Moore wrote:

On Sat, 4 Jul 2020 at 17:48, MRAB wrote:

...

On 2020-07-04 05:51, Greg Ewing wrote:

...

On 4/07/20 4:33 am, Jim J. Jewett wrote:

...

If Bob and Alice seem neutral to you, would you do a double-take on Kehinde or Oladotun?

Maybe we should use randomly generated names for hypothetical persons?

Ideally they should be short names, one or two syllables.

Surely the obvious thing to do would be to use Monty Python characters? True, but if they were all called Eric it could be confusing.

On 04/07/2020 21:23, MRAB wrote:

On 2020-07-04 19:23, Paul Moore wrote:

...

On Sat, 4 Jul 2020 at 17:48, MRAB wrote:

...

On 2020-07-04 05:51, Greg Ewing wrote:

...

On 4/07/20 4:33 am, Jim J. Jewett wrote:

...

If Bob and Alice seem neutral to you, would you do a double-take

...

...

Maybe we should use randomly generated names for hypothetical

on Kehinde or Oladotun? persons?

...

...

Ideally they should be short names, one or two syllables.

Surely the obvious thing to do would be to use Monty Python characters? True, but if they were all called Eric it could be confusing.

Yes, we'd have to call them Bruce to avoid confusion. -- Rhodri James *-* Kynesim Ltd

On 7/2/2020 7:39 AM, Tim Peters wrote:

Then again, we're talking about humans. There's nothing you can do - or refrain from doing - that won't mortally offend someone:-) This is the truest thing spoken in this whole thread.

On Fri, Jul 3, 2020 at 4:09 AM David Mertz 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 wrote:

On 02.07.2020 21:20, Chris Angelico wrote:

...

On Fri, Jul 3, 2020 at 4:09 AM David Mertz 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).

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.

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 wrote:

On Thu, 2 Jul 2020 at 20:33, Chris Angelico wrote:

...

On Fri, Jul 3, 2020 at 5:17 AM Ivan Pozdeev via Python-Dev 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.

...

I think I agree. The consequences would be notable, but not untenable.

I disagree that this should be done. When has this been done/requested before for a commit message that is already merged?

...

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.

-1 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DQOPEM6W... Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, Jul 2, 2020 at 8:34 PM Łukasz Langa 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?

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 03.07.2020 3:10, Łukasz Langa wrote:

...

On 2 Jul 2020, at 21:38, Chris Angelico wrote:

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

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.

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.

- Ł _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RED5C5ML... Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan

On 03.07.2020 15:01, Henk-Jaap Wagenaar wrote:

On Fri, 3 Jul 2020 at 08:50, Ivan Pozdeev via Python-Dev mailto:python-dev@python.org> wrote:

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

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.

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.

-- Regards, Ivan

On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote:

On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev mailto:vano@mail.mipt.ru> wrote:

So what?

Unnecessary

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

That is not a very collaborative mindset.

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.

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

-- Regards, Ivan

On Fri, 3 Jul 2020 at 14:28, Chris Angelico wrote:

On Fri, Jul 3, 2020 at 11:03 PM Ivan Pozdeev via Python-Dev wrote:

...

On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote:

On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev wrote:

...

So what?

Unnecessary

...

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

...

That is not a very collaborative mindset.

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.

...

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?

...

Even if someone isn't aware of the change, the PEPs repo *already* rewrites commits as they get merged,

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.

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.

Maybe, but rewriting it would (a) not make the "hassle" go away and (b) would in my view create more "hassle".

ChrisA _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/W3UOLWJZ... Code of Conduct: http://python.org/psf/codeofconduct/

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

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:

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

...

On Fri, Jul 3, 2020 at 4:09 AM David Mertz 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

--------------------------------------------------- Date: Thu, 2 Jul 2020 21:33:56 +0300 From: Ivan Pozdeev Subject: [Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou) To: python-dev@python.org Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed On 02.07.2020 21:20, Chris Angelico wrote: 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).

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.

...

ChrisA _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/A2XBFOH5... Code of Conduct: http://python.org/psf/codeofconduct/ http://python.org/psf/codeofconduct/ -- Regards, Ivan

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZZKGBARO... Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan

On 7/2/2020 6:49 PM, Rémi Lapeyre wrote:

...

Le 3 juil. 2020 à 00:32, Ivan Pozdeev via Python-Dev mailto:python-dev@python.org> a écrit :

Athttps://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.

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, 2 Jul 2020 at 21:18, David Antonini 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