[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/PJQ2HBYLELRGSZ2DPVZED6CJCPE2YR6Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/PEFPBAMWAFW4VVZAKSD2O2PDJ6OEZH7B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/KAY3WEL7XTG6527FM2HSA747D2T27T6E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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/045450aaf47941f3ee7daaa1774947b31885b2aa > 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-le...@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/W3UOLWJZHRLJA75PJZ5O434FPPLBZMLQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/PG7U3HQOCQVMQFUQ5CPGGX5F4FIV3MHP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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, 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/045450aaf47941f3ee7daaa1774947b31885b2aa 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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/W3UOLWJZHRLJA75PJZ5O434FPPLBZMLQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote: On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev mailto:v...@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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/4MQYGI44AZT66SOHZDDYQVQXZBZTNEEU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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. 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!). > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/55F6YYVAHRRIGUCXZQWZNUKK3LSDDNYZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/7CZMBZUCD4VV3RQPFC3CNZTP7RVDWYRZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/, we're talking about an infinitely less impactful peps repo (per https://mail.python.org/archives/list/python-dev@python.org/message/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/, 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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/WIUPJNTWRHJHJR6AMPKXCWT4F4K4IJQF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
On Fri, 3 Jul 2020 at 08:50, Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > > Per > https://mail.python.org/archives/list/python-dev@python.org/message/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/, > we're talking about an infinitely > less impactful peps repo (per > https://mail.python.org/archives/list/python-dev@python.org/message/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/, > 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. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/ICEY5RDK7P7VWDXH7W6JI76SO57JZB4I/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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/T7CM4AUJFQN5WDZ5E4PIR7IIK7AOPRTE/, "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/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/, we're talking about an infinitely less impactful peps repo (per https://mail.python.org/archives/list/python-dev@python.org/message/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/, 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-le...@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/RED5C5ML2BIOS4RZ23O7M2D3WZKUSPCW/ Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/BC5XAXFHEUEIVMD6CUBEV5SJDBR2NAME/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
On Fri, Jul 3, 2020 at 10:10 AM Ł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? > 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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/LFXOHCAO5RTIRGQQQIR4IWZY5YVLY2F5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/7AIF2N4URXWNGAL4FP2I3BFWNJZ5AX5F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
> 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? 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-le...@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/RED5C5ML2BIOS4RZ23O7M2D3WZKUSPCW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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-le...@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/DQOPEM6WVVKGB7KHV7XIEWJ5Z7MQMAHW/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/FTR4YOP4WD6DIOND5HXYB7A223VSXASN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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-le...@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/DQOPEM6WVVKGB7KHV7XIEWJ5Z7MQMAHW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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/changing-a-commit-message. > >> 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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/NOJE4SL3GTYH4U5WYXMWA4POJDSJSLEQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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/changing-a-commit-message. 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. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/A2XBFOH5WGEOASSXHHKRWEHMZBN625SU/ Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/QIAJS7264QPH4PXBHJKLR2M7YVXX2SIG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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/changing-a-commit-message. > 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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/A2XBFOH5WGEOASSXHHKRWEHMZBN625SU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
On Thu, Jul 2, 2020 at 1:36 PM David Antonini wrote: > 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? > 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. > 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/changing-a-commit-message. 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. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/ASRVRXDXHAQZFE2CCBBTU4SU43PLLRCS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
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 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 wrote: > Standardizing on a > single language ensures that everyone can read the comments in a > single, consistent language. 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. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/KSBGDA3OYU2EMMD2MLXNGZFGHYSLVEZW/ Code of Conduct: http://python.org/psf/codeofconduct/
