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
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
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 "tabl
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
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 t
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
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
>
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 commun
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
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/ar
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
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
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 re
> 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 w
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:
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 ag
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 consideratio
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
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 woul
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 Ame
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 an
21 matches
Mail list logo