[Python-Dev] Re: Recent PEP-8 change

[Antoine Pitrou]

On Thu, 2 Jul 2020 01:40:56 +0100
Henk-Jaap Wagenaar  wrote:
> 
> 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.

We're not talking about posting "your own writing", we're talking about
comments (and presumably documentation) in a collective software
project.  There's a need for consistency, however it's
specified and achieved.

Otherwise why stop at English? I could just as well write my comments
in French if it's all about individual freedom.  Requiring English is
not inclusive, it forced people like me to painfully adapt to a
language I wasn't used to.  And that has nothing to do with "white
supremacy".

Regards

Antoine.

___
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/HFDK7PL5NLM3RMAP7VBKCPCKDFMHNTNB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Chris Angelico]

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
___
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/GUNLZDGNHZXQPMTCONR5MY3HP2NG52TH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Antoine Pitrou]

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/4GI2LY47Z5MCRRSKEIS4PR6ONDRCWVQV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Stable ABI question.

[Victor Stinner]

Hi,

Last time I looked at PyEval_AcquireLock(), it was used in the wild,
but I don't recall exactly where, sorry :-( Before removing the
functions, I suggest to first notify impacted projects of the incoming
removal, and maybe even propose a fix. I suggest to attempt to follow
the process that I proposed in the PEP 620:
https://www.python.org/dev/peps/pep-0620/#process-to-reduce-the-number-of-broken-c-extensions

For a concrete example, see this JEP issue:
https://github.com/ninia/jep/issues/229

Getting rid of PyEval_AcquireLock() and PyEval_ReleaseLock() in JEP
doesn't seem trivial. This project uses subinterpreters and uses/used
daemon threads.


At least, I tested with my pythonci project (*) and it's possible to
build Cython, numpy and lxml without PyEval_AcquireLock() and
PyEval_ReleaseLock() (they don't use these functions).

(*) https://github.com/vstinner/pythonci


Previously, PyEval_ReleaseLock() was used by
PyThreadState_DeleteCurrent(). I introduced a new
_PyEval_ReleaseLock() function which takes a tstate parameter, so
Python no longer uses PyEval_AcquireLock() and PyEval_ReleaseLock().

commit 23ef89db7ae46d160650263cc80479c2ed6693fb
Author: Victor Stinner 
Date:   Wed Mar 18 02:26:04 2020 +0100

bpo-39984: _PyThreadState_DeleteCurrent() takes tstate (GH-19051)

* _PyThreadState_DeleteCurrent() now takes tstate rather than
  runtime.
* Add ensure_tstate_not_null() helper to pystate.c.
* Add _PyEval_ReleaseLock() function.
* _PyThreadState_DeleteCurrent() now calls
  _PyEval_ReleaseLock(tstate) and frees PyThreadState memory after
  this call, not before.
* PyGILState_Release(): rename "tcur" variable to "tstate".

Victor




Le mer. 1 juil. 2020 à 03:39, Inada Naoki  a écrit :
>
> Hi, folks.
>
> I found PyEval_AcquireLock and PyEval_ReleaseLock are deprecated since
> Python 3.2.
> But the same time, stable ABI is defined in Python 3.2 too.
> The deprecated APIs are stable ABI too because `ceval.h` is not
> excluded from the stable ABI PEP.
>
> As far as my understanding, we can not remove them until Python 4.0. Am I 
> right?
>
> I will add comment like this.
> /* This is a part of stable ABI. Do not remove until Python 4.0 */
>
> Regards,
> --
> Inada Naoki  
> ___
> 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/EJF67ZM2HMLWCVKAYNU4JCATO7CRILOS/
> Code of Conduct: http://python.org/psf/codeofconduct/



--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/CLGCJDR6NTL7ILYFRZCATLLB4JU2RGGM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

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.
___
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/2S4TQASCPZKPHYXMCC43ZNKRLWBZN2BW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Greg Ewing]

On 2/07/20 10:53 pm, MRAB wrote:

Alternatively, it could be an auxiliary language like Esperanto.


Maybe Esperanto in particular wouldn't be the best choice --
I gather it's rather European-oriented.

Maybe we should standardise on Klingon? Humans of all cultures
would find it equally difficult.

--
Greg
___
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/I62MWRZZHFKULJN7TYY2GNNF2D25VZCI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Barry Scott]

> On 29 Jun 2020, at 10:57, Victor Stinner  wrote:
> 
> I would prefer to only have a fast-path for the most common encodings:
> ASCII, Latin1, UTF-8, Windows ANSI code page. That's all.

It's not obvious to me why the latin1 encoding is in this list as its just one 
of all the 8-bit char sets.
Why is it needed?

Barry

___
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/XGJ5NG4WPJKUOZY7KPWD2R3FP6XJDXPM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Paul Moore]

Latin-1 is the encoding that maps every byte (0-255) to the Unicode
character with the same number. So it's special in that sense, and it
gets used when mapping 8-bit bytes via Unicode "without encoding".
Excuse my imprecise language here, I don't know the correct Unicode
terms without going & looking them up.

Paul

On Thu, 2 Jul 2020 at 13:48, Barry Scott  wrote:
>
>
>
> On 29 Jun 2020, at 10:57, Victor Stinner  wrote:
>
> I would prefer to only have a fast-path for the most common encodings:
> ASCII, Latin1, UTF-8, Windows ANSI code page. That's all.
>
>
> It's not obvious to me why the latin1 encoding is in this list as its just 
> one of all the 8-bit char sets.
> Why is it needed?
>
> Barry
>
> ___
> 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/XGJ5NG4WPJKUOZY7KPWD2R3FP6XJDXPM/
> 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/QPFM5L5UEKTICPDVFIE3NT5M7RX4C4ID/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Victor Stinner]

Le jeu. 2 juil. 2020 à 14:44, Barry Scott  a écrit :
> It's not obvious to me why the latin1 encoding is in this list as its just 
> one of all the 8-bit char sets.
> Why is it needed?

The Latin-1 (ISO 8859-1) charset is kind of special: it maps bytes
0x00-0xFF to Unicode characters U+-U+00FF and decoding from latin1
cannot fail.

It was commonly used as the locale encoding in Europe 10 years ago,
but nowadays most Linux distributions use UTF-8 as the locale
encoding.

I'm also fine with restricting the list to 3 encodings: ASCII, UTF-8
and Windows ANSI code page.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/YWL3WU3PN7NXIGZNLIBLAO7O225VF46C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Barry Scott]

> On 30 Jun 2020, at 13:43, Emily Bowman  wrote:
> 
> I completely agree with this, that UTF-8 has become the One True 
> Encoding(tm), and UCS-2 and UTF-16 are hardly found anywhere outside of the 
> Win32 API. Nearly all basic emoji can't be represented in UCS-2 wchar_t, let 
> alone composite emoji.
> 

I use UCS-32 in my extensions, but never persist UCS-32 for which I use UTF-8.

If you are calling WIN32 "unicode" APIs then you need UCS-16.

My plan with PyCXX is to replace Py_UNICODE with UCS-32.
I think all the UCS-32 APIs will still be present.

Once I add that support to PyCXX all my users should easily port to a 
non-Py_UNICODE world.

Barry

___
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/YIKT5XGPZIMEIAPBJS3OQAZTWW4JM3Z2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Henk-Jaap Wagenaar]

On Tue, 30 Jun 2020 at 11:49, Ethan Furman  wrote:

> - it has been modernized as times have changed (the 2000 edition removed
> the advice
>to use masculine pronouns whenever possible, and warns that some will
> find unnecessary
>masculine usage offensive)
>

PEP-8 however does not mention a particular edition and the version that is
readily available (in the public domain) does contain this problematic
section "to use the masculine pronouns whenever possible" which is not
inclusive. Hence, I think we would be better off not mentioning it or
failing that, mentioning a particular edition. I think times/language norms
for inclusivity have changed a lot since 2000 (two decades), so another
style guide that was more recently updated might be better, if we think
there should be one mentioned at all.

This is the version I found on Gutenberg:
http://www.gutenberg.org/files/37134/37134-h/37134-h.htm and the particular
problematic section I mentioned is this:


> 'They. A common inaccuracy is the use of the plural pronoun when the
> antecedent is a distributive expression such as each, each one, everybody,
> every one, many a man, which, though implying more than one person,
> requires the pronoun to be in the singular. Similar to this, but with even
> less justification, is the use of the plural pronoun with the antecedent
> anybody, any one, somebody, some one, the intention being either to avoid
> the awkward “he or she,” or to avoid committing oneself to either. Some
> bashful speakers even say, “A friend of mine told me that they, etc.”



Use he with all the above words, unless the antecedent is or must be
> feminine.'
___
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/K5UISYDXKYKSGOVRDQEWUELCOM5GPJUL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

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.

___
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/A7V3LK44XW7WFB67S7UTT7ZU7HLEFKME/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Paul Moore]

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

Paul
___
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/O7JTHQNC62L7XSNIX3JN2GAZUU6INCD6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Victor Stinner]

UCS-2 means units of 16 bits so it's limited to Unicode BMP: U+-U+.

UCS-4 means units of 32 bits and so gives access to the whole
(current) Unicode character set.

Do you mean UTF-16 and UTF-32? UTF-16 supports the whole Unicode
character set but uses the annoying surrogate pairs for characters
outside the BMP.*

UTF-32 is UCS-4 in practice.

Victor

Le jeu. 2 juil. 2020 à 15:08, Barry Scott  a écrit :
>
>
>
> On 30 Jun 2020, at 13:43, Emily Bowman  wrote:
>
> I completely agree with this, that UTF-8 has become the One True 
> Encoding(tm), and UCS-2 and UTF-16 are hardly found anywhere outside of the 
> Win32 API. Nearly all basic emoji can't be represented in UCS-2 wchar_t, let 
> alone composite emoji.
>
>
> I use UCS-32 in my extensions, but never persist UCS-32 for which I use UTF-8.
>
> If you are calling WIN32 "unicode" APIs then you need UCS-16.
>
> My plan with PyCXX is to replace Py_UNICODE with UCS-32.
> I think all the UCS-32 APIs will still be present.
>
> Once I add that support to PyCXX all my users should easily port to a 
> non-Py_UNICODE world.
>
> Barry
>
> ___
> 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/YIKT5XGPZIMEIAPBJS3OQAZTWW4JM3Z2/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/K5MKE6EDM7HKAGFXQ4EYWKACDX6OCFFH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Inada Naoki]

On Thu, Jul 2, 2020 at 6:40 PM Chris Angelico  wrote:
>
> True, but "inclusive" isn't just about the people *writing*. If you
> write your comments in French, and someone else uses Turkish, another
> uses Japanese, and still another opts for Hebrew, it becomes nearly
> impossible for anyone to *read* those comments. Standardizing on a
> single language ensures that everyone can read the comments in a
> single, consistent language.
>

Thank you for mentioning Japanese.
I totally agree with you. Readability counts, not writability.

I am not good at English. I can not live in English world. I don't
understand many proverbs
and idioms. I may not be able to buy even food!

But I can read technical documents like RFC. English used in RFC is
very clear to me.
I don't know English in RFC is S&W English or not. But I believe
English used in RFC is
very inclusive for the engineers in the world.

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

Regards,
-- 
Inada Naoki  
___
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/U5DZGTW77BUOL3L6TRQDBBRBPVNZVB6C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Antoine Pitrou]

On Thu, 2 Jul 2020 14:52:04 +0100
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 :-(

There's no good answer because "good" depends on the morality of the
day, and things that used to be "good enough" are now considered (at
least by some and/or in some contexts) to be "evil".  And whatever seems
good today might well become horrible in two decades.

Which, actually, is a good argument to let language lag behind the
times, because at least you can ensure some reasonable stability in
communication conventions.  If you change conventions every decade, how
will you read texts from the past?

Regards

Antoine.

___
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/C6UFSWTDIOOLZFQFLXZ67FV663VEK2QQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Rhodri James]

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
___
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/ECFLQNMKIX4RRBHDAHM4NMGKSDOHX76R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Greg Ewing]

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
___
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/26ZRXGQQOFTWHS74M4XGFMREM7IIB3SY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Tim Peters]

[Paul Moore ]
> (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 :-(

I've used singular "they" for years'; if someone truly objects to
that, they've kept it to themself.

"Authorities" are moving in that direction too; e.g.,

https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they

"""
The singular “they” is a generic third-person singular pronoun in
English. Use of the singular “they” is endorsed as part of APA Style
because it is inclusive of all people and helps writers avoid making
assumptions about gender. Although usage of the singular “they” was
once discouraged in academic writing, many advocacy groups and
publishers have accepted and endorsed it, including Merriam-Webster’s
Dictionary.
"""

Then again, we're talking about humans.  There's nothing you can do -
or refrain from doing - that won't mortally offend someone :-)
___
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/4MOBYZJUEMUKKI2GELZNXTRMT7QPRGR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Petr Viktorin]

On 2020-07-02 14:57, Victor Stinner wrote:

Le jeu. 2 juil. 2020 à 14:44, Barry Scott  a écrit :

It's not obvious to me why the latin1 encoding is in this list as its just one 
of all the 8-bit char sets.
Why is it needed?


The Latin-1 (ISO 8859-1) charset is kind of special: it maps bytes
0x00-0xFF to Unicode characters U+-U+00FF and decoding from latin1
cannot fail.


This apparently makes it useful for not-quite-text, not-quite-bytes 
protocols like HTTP. In particular, WSGI (PEP ) uses latin-1 for 
headers.




It was commonly used as the locale encoding in Europe 10 years ago,
but nowadays most Linux distributions use UTF-8 as the locale
encoding.

I'm also fine with restricting the list to 3 encodings: ASCII, UTF-8
and Windows ANSI code page.


___
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/DQI2UW5WOQ3EMHRP5VEGDG3MIU364I6K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Piper Thunstrom]

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
___
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/OSTXWM64JZ4NEKJ7D7VKSHB6BJL4QNQL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Jim J. Jewett]

Guido van Rossum wrote:
> On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan ncogh...@gmail.com wrote:
> > The key thing I'm hoping for in PEP 622 itself is
> > that "Syntactic compatibility with a possible future
> > enhancement to assignment statements" be considered
> > as a constraint on the syntax for case patterns.

> That would certainly rule out ideas like writing stores as $x or x? or 
> etc., since it would be syntactically incompatible with current
> assignment statements.

No; it would be unfortunate that it creates a second way to 
do things, but it wouldn't rule them out.  The problem Nick
pointed out is for syntax that is already meaningful, but
means something different.

self.y = 15

already has a meaning, but that meaning is NOT "don't really
assign to X, I am using it as a constant defined elsewhere."

?x = 14
?self.y = 15

do not yet mean anything, and if they end up being a more
explicit (but also more verbose) variant of

x = 14
self.y = 15

that is probably sub-optimal, but it isn't any worse than :=

The slight variation triggered by the "?" of ?var would be 
shorthand for "and if you can't make the entire assignment 
work, pretend I never even asked", so that

?x, 0 = (4,5) 

would not lose or shadow a previous binding of x.
 
-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/WT4UTNYJ2RIX25UZQVQN7PO7QYQ3F4JR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Éric Araujo]

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
___
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/5BPV75H6VOCF45EV3A2B2G2QDEIMXWCA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Henk-Jaap Wagenaar]

On Thu, 2 Jul 2020 at 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 :-(
>
> Paul
>

As others have said and more eloquently, I use and would suggest to use
(singular) "they" or rephrase it. Furthermore, I have seen no rationale
against "they" that I think holds any water (though of course, now one will
surface!) and I have not seen it criticized recently. It seems incredibly
common in circles I frequent that when an old document is reviewed every
occurence of "he" is simply replaced with "they".
___
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/VDOMLNPBJEK5YNV5FRCFK23C6QNTGKG6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Henk-Jaap Wagenaar]

On Thu, 2 Jul 2020 at 16:16, Éric Araujo  wrote:

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

I do not think that technique is as inclusive as we should aim to be
(apologies if I get this wrong in terms of gender v.s. sex): there are
those who do not self-identify as either gender or prefer another pronoun
(I know some who prefer to be called "they" instead of he or she and do not
identify as male or female): hence using (singular) they is simply easiest
and unoffensive (in my view).
___
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/PUAZ7LHRVGYG5DS4TJTTQGUTOO4UZEH2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] destructuring with class constructors

[Jim J. Jewett]

Nick Coghlan wrote:
> On Thu, 2 Jul 2020 at 00:50, Guido van Rossum gu...@python.org wrote:

> > As to allowing object destructuring syntax like
> > Point(x, y) = p

> > that definitely has merit, but it is a complex subject that should be a 
> > separate
> > PEP.

> This is the main point I'm actually interested in, and I agree it
> should be a separate PEP.

I also like it, but I don't see a way to actually do it usefully without 
changing how Python works.  The glitch is for cases like:

Point(?x, 15) = p

If constraints like (y=15) are not allowed, then it doesn't really offer much
advantage over a regular constructor like:

Point(*p)

But if they are allowed, then what does it mean?

 Point(p[0], 15) 

would be logical, but still not very valuable.  At the very least, it should be
able to reject:

Point(x, y) = ("Hello", "World")

but it isn't clear how much of the constructor (let alone some other
arbitrary callable) to run before saying "yeah, it meets the contract",
unless type annotations and their "correct" meaning become even
more constrained, so that:

Point(x:int, y:int) = ("Hello", "World")

could fail, because "Hello" is not an int.  But that is just a very weak 
Design By Contract that both constrains the meaning of annotations 
and still leaves out most interesting contracts. 

-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/ZCDCBE3U3WUZZTKOXYA6ZFXUH3MV6SUK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Rhodri James]

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
___
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/G56XDSCQ2GJPUFZ2LWWB45J2WZ62WILH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[David Mertz]

Inado-san makes a very good point.

The (English) language used in technical documents is not AAVE. It's not
Scotts-English. It's not Jamaican vernacular. It's not Indian English. But
it is ALSO not American upper-middle class, white ivy-league English.

Technical documentation is a kind of DSL within the world of English
dialects. There is a greatly restricted vocabulary and grammar used for
this purpose, and no native speaker or writer doing "ordinary"
communication would use this DSL.

On Thu, Jul 2, 2020, 10:35 AM Inada Naoki  wrote:

> On Thu, Jul 2, 2020 at 6:40 PM Chris Angelico  wrote:
> >
> > True, but "inclusive" isn't just about the people *writing*. If you
> > write your comments in French, and someone else uses Turkish, another
> > uses Japanese, and still another opts for Hebrew, it becomes nearly
> > impossible for anyone to *read* those comments. Standardizing on a
> > single language ensures that everyone can read the comments in a
> > single, consistent language.
> >
>
> Thank you for mentioning Japanese.
> I totally agree with you. Readability counts, not writability.
>
> I am not good at English. I can not live in English world. I don't
> understand many proverbs
> and idioms. I may not be able to buy even food!
>
> But I can read technical documents like RFC. English used in RFC is
> very clear to me.
> I don't know English in RFC is S&W English or not. But I believe
> English used in RFC is
> very inclusive for the engineers in the world.
>
> I don't think I can write such clear English without help. But having
> such a goal is inclusive
> for non native English readers.
>
> Regards,
> --
> Inada Naoki  
> ___
> 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/U5DZGTW77BUOL3L6TRQDBBRBPVNZVB6C/
> 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/A6UQ3BSSSINX3F3JG4MDOQPKIRVW53UD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Stefan Behnel]

Victor Stinner schrieb am 02.07.20 um 00:07:
> Le mer. 1 juil. 2020 à 23:43, Eric V. Smith a écrit :
>>
>> On 7/1/2020 3:43 PM, Stefan Behnel wrote:
>>> Petr Viktorin schrieb am 30.06.20 um 14:51:
 For example, could we only deprecate the bad parts, but not remove them
 until the experiments actually show that they are preventing a beneficial
 change?
>>> Big nod on this one.
>>
>> At one of the core sprints (maybe at Microsoft?) there was talk of
>> adding a new API without changing the existing one.
>>
> There is the https://github.com/pyhandle/hpy project which is
> implemented on top of the existing C API.
> 
> But this project doesn't solve problems listed in PEP 620, since
> CPython must continue to support existing C extensions.
Maybe I'm missing something here, but how is "removing parts of the C-API"
the same as "supporting existing C extensions" ? It seems to me that both
are straight opposites.

Stefan
___
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/U6HIYIHPIHSNRIG4IYUTQESJTUXKGOXC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[David Mertz]

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.

The usage has never been rare during those 650 years, but neither has it
ever been predominant. It is a completely reasonable approach, and I would
not object to encouraging it in Python documentation.

Earlier in my life (30-40 years ago) I tended to use s/he or similar forms.
I think that 'they' is more inclusive of gender non-binary people, as well
as being much more historically established.


> "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
> ___
> 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/OSTXWM64JZ4NEKJ7D7VKSHB6BJL4QNQL/
> 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/X2DCHJBRU3JPLBGC3P7OTBYCOGXS5H3P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

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.
___
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/MIW6WHPO7NZ5UNVPFOIGWH2CI6Y3B5JN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Paul Moore]

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
___
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/K2OG5XL3WA4TERVOPLGCLBKBTFBOH2DG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[MRAB]

On 2020-07-02 15:48, Jim J. Jewett wrote:

Guido van Rossum wrote:

On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan ncogh...@gmail.com wrote:
> The key thing I'm hoping for in PEP 622 itself is
> that "Syntactic compatibility with a possible future
> enhancement to assignment statements" be considered
> as a constraint on the syntax for case patterns.



That would certainly rule out ideas like writing stores as $x or x? or 
etc., since it would be syntactically incompatible with current
assignment statements.


No; it would be unfortunate that it creates a second way to
do things, but it wouldn't rule them out.  The problem Nick
pointed out is for syntax that is already meaningful, but
means something different.

 self.y = 15

already has a meaning, but that meaning is NOT "don't really
assign to X, I am using it as a constant defined elsewhere."

 ?x = 14
 ?self.y = 15

do not yet mean anything, and if they end up being a more
explicit (but also more verbose) variant of

 x = 14
 self.y = 15

that is probably sub-optimal, but it isn't any worse than :=

The slight variation triggered by the "?" of ?var would be
shorthand for "and if you can't make the entire assignment
work, pretend I never even asked", so that

 ?x, 0 = (4,5)

would not lose or shadow a previous binding of x.
  
IMHO, the assignment statement should remain as it is, not sometimes 
assign and sometimes not.


There could be another form that does matching:

try ?x, 0 = (4,5)

or:

?x, 0 ?= (4,5)

Perhaps it could also be used as an expression, having the value True if 
it matches and False if it doesn't.

___
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/MQV7WBASYRI7PJT5M2VUCPHKBZLXDMY2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

On 2020-07-02 17:14, Paul Moore wrote:

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.

Indo-European languages tend to have grammatical gender 
(masculine/feminine/neuter or masculine/feminine), but it's not 
necessarily related to physical gender.


Other languages families might have many categories or 'genders', or 
just distinguish between animate and inanimate (and those might not 
necessarily be related to whether something is really animate or inanimate).


Having only one 3rd-person singular pronoun is by no means unusual.
___
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/N4KCCO4FCANKMBRVA6VQZR6QSKJGTWYH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Piper Thunstrom]

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.

Piper Thunstrom

My public key is available at https://keybase.io/pathunstrom
Public key fingerprint: 8FF9 3F4E C447 55EC 4658 BDCC A57E A7A4 86D2 644F


>
> On 2020-07-02 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.)
> >

> ___
> 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/MIW6WHPO7NZ5UNVPFOIGWH2CI6Y3B5JN/
> 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/LUWNVGAGQ6DGXPNIB5XEDWRQXHPSJNKQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Eric V. Smith]

On 7/2/2020 11:36 AM, Stefan Behnel wrote:

Victor Stinner schrieb am 02.07.20 um 00:07:

Le mer. 1 juil. 2020 à 23:43, Eric V. Smith a écrit :

On 7/1/2020 3:43 PM, Stefan Behnel wrote:

Petr Viktorin schrieb am 30.06.20 um 14:51:

For example, could we only deprecate the bad parts, but not remove them
until the experiments actually show that they are preventing a beneficial
change?

Big nod on this one.

At one of the core sprints (maybe at Microsoft?) there was talk of
adding a new API without changing the existing one.


There is the https://github.com/pyhandle/hpy project which is
implemented on top of the existing C API.

But this project doesn't solve problems listed in PEP 620, since
CPython must continue to support existing C extensions.

Maybe I'm missing something here, but how is "removing parts of the C-API"
the same as "supporting existing C extensions" ? It seems to me that both
are straight opposites.


Agreed. I thought the discussion was "in CPython, leave the existing 
C-API alone, but experiment with new APIs, and then maybe someday 
deprecate the existing C-API". I could see  conditionally disabling the 
existing C-API if doing so was needed to do something like experimenting 
with remove reference counting. But for the foreseeable future, we'd 
ship with the existing C-API until we'd determined a significant benefit 
to dropping it.


Eric
___
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/O43OF6EOLH72FBU6A5MZ2EYNLUI3NBKD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Walter Dörwald]

On 1 Jul 2020, at 18:54, Brandt Bucher wrote:


Walter Dörwald wrote:
This looks strange to me. In all other cases of variable lookup the 
global variable z would be found.


The next case assigns to z, making z local to whereis. This is 
consistent with python's existing scoping rules (for example, try 
rewriting this as the equivalent if-elif chain and you'll get the same 
error). It sounds like you want to add "global z" to the top of the 
function definition.



whereis(23) however works.


This branch is hit before the unbound local lookup is attempted.


OK, understood.

However I still find the rule "dotted names are looked up" and "undotted 
names are matched" surprising and "case .constant" ugly.


A way to solve this would be to use "names at the top level are always 
looked up".


With this the constant value pattern:

case .name:

could be written as:

case name:

The capture pattern (of which there can only be one anyway) could then 
be written as:


case object(name):

instead of

case name:

Or we could use "matches are always done against a match object", i.e. 
the code from the example would look like this:


from dataclasses import dataclass

@dataclass
class Point:
x: int
y: int

z = 42

def whereis(point):
w = 23
match point as m:
case Point(0, 0):
print("Origin")
case Point(0, m.y):
print(f"Y={m.y}")
case Point(m.x, 0):
print(f"X={m.x}")
case Point():
print("Somewhere else")
case w:
print("Not the answer")
case z:
print("The answer")
case object(z):
print(f"{z!r} is not a point")

Servus,
   Walter
___
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/SPMTCDIRJJGCKSIPWE4EX6DSIBFXLAL4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[David Mertz]

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
 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.
___
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/ZUIXRMF3ICROMO3HMGQNR2FB3IPXIEE6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

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.
___
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/6YZVBQBU3XI72F4LFU4IRRBHWVYKA5XM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[David Antonini]

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/

[Python-Dev] Re: Recent PEP-8 change

[David Mertz]

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.
___
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/7KH5ZDMBRQFPCSBOAMGO43NDPQK7A5LD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Rhodri James]

On 02/07/2020 18:12, MRAB wrote:

English isn't Latin.


Bizarre as it may sound, I still occasionally find that hard to 
remember.  My English Language teachers were only really interested in 
teaching English Literature, and considered grammar to be one of those 
unfortunate things it was better to hide from students.  It was in Latin 
classes that I learned how sentences are put together, and that's what I 
default to when I'm not thinking hard enough.


--
Rhodri James *-* Kynesim Ltd
___
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/B323CAMMYNWEVQIFWTMHS7DK3LSJBGE6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Rhodri James]

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
___
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/KO7QFT5IEZM7RPKC4CAQFT46WPHLVP2L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[David Mertz]

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

[MRAB]

On 2020-07-02 18:19, David Mertz wrote:
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.`

And if you don't like singular "they", an alternative that I forgot 
about is "yon", as in this/that/yon (this near me; that near you; yon 
over there by him/her/it). English had 3 demonstratives, as did Latin, 
as does Spanish.


___
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/2PSWJWJITO5TPFHQP5TCGFDQI4BHEHAI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Glenn Linderman]

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.
___
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/SLGATIV7XP4C4SQHSALP7LNQ5CQMNIP6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[Chris Angelico]

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: Flexible assignment targets

[Paul Ganssle]

I think that creating a "matching assignment" operator is unnecessary at
this point. I think the original point of bringing this up as part of
PEP 622 is to try to suggest that the syntax for binding a value not be
incompatible with a future version of Python where that same syntax can
be used for any kind of assignment. That goal is not satisfied for all
cases if `case self.x` means anything except "bind the value to `self.x`".

I think that you /could /probably still use $, ? or <> to mark a
variable to be bound, but it would /not/ be worth the effort to make it
mandatory for lvalues in general, and if you make it optional I imagine
it would be rarely used, and you'd get effectively no benefit from
supporting that (since people would just be confused whenever they saw it).

I think that leaves as /realistic/ options here to either abandon the
idea of marking read vs. store, put the marker on variables to be read
(and have it be something other than "there is a . anywhere in the
expression"), or abandon the goal of allowing for perfect symmetry
between lvalues in case statements and lvalues in assignments.

I tend to think "mark all reads" is the best course of action here, and
stuff like `case self.x` would be a `SyntaxError` (like it is with
assignment expressions).

On 7/2/20 12:26 PM, MRAB wrote:
> On 2020-07-02 15:48, Jim J. Jewett wrote:
>> Guido van Rossum wrote:
>>> On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan ncogh...@gmail.com wrote:
>>> > The key thing I'm hoping for in PEP 622 itself is
>>> > that "Syntactic compatibility with a possible future
>>> > enhancement to assignment statements" be considered
>>> > as a constraint on the syntax for case patterns.
>>
>>> That would certainly rule out ideas like writing stores as $x or x?
>>> or 
>>> etc., since it would be syntactically incompatible with current
>>> assignment statements.
>>
>> No; it would be unfortunate that it creates a second way to
>> do things, but it wouldn't rule them out.  The problem Nick
>> pointed out is for syntax that is already meaningful, but
>> means something different.
>>
>>  self.y = 15
>>
>> already has a meaning, but that meaning is NOT "don't really
>> assign to X, I am using it as a constant defined elsewhere."
>>
>>  ?x = 14
>>  ?self.y = 15
>>
>> do not yet mean anything, and if they end up being a more
>> explicit (but also more verbose) variant of
>>
>>  x = 14
>>  self.y = 15
>>
>> that is probably sub-optimal, but it isn't any worse than :=
>>
>> The slight variation triggered by the "?" of ?var would be
>> shorthand for "and if you can't make the entire assignment
>> work, pretend I never even asked", so that
>>
>>  ?x, 0 = (4,5)
>>
>> would not lose or shadow a previous binding of x.
>>   
> IMHO, the assignment statement should remain as it is, not sometimes
> assign and sometimes not.
>
> There could be another form that does matching:
>
>     try ?x, 0 = (4,5)
>
> or:
>
>     ?x, 0 ?= (4,5)
>
> Perhaps it could also be used as an expression, having the value True
> if it matches and False if it doesn't.
> ___
> 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/MQV7WBASYRI7PJT5M2VUCPHKBZLXDMY2/
> Code of Conduct: http://python.org/psf/codeofconduct/


signature.asc
Description: OpenPGP digital signature
___
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/XCHCK7ZXS3OEKOLRGJGS7USFXGBFSIBT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Ethan Furman]

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~
___
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/PXIGCD7WDFUHRP35RLGKD3UMNABVSGFO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Brett Cannon]

It's off the table from the perspective of PEP 622 and its authors. If you
want to write a competing PEP that proposes your idea that's totally fine.

On Wed, Jul 1, 2020 at 8:17 PM Elliott Chen 
wrote:

> I don't think my proposal should be off the table for scope reasons
> because it requires the syntaxes to be completely unified and
> interchangeable, which will be impossible if the current PEP is accepted. I
> guess it's technically possible to still have the pattern-matching syntax
> be slightly different from extended assignment statements, but I think that
> would just unnecessarily complicate the language, force users to be aware
> of the subtle differences when writing code, and potentially cause users to
> make mistakes.
> ___
> 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/HF3ALPHOKKCT4ZNI5JV54L5QLDBGWRFQ/
> 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/QHFWMQR7X7HMITYXDEBPWAGJ422KWUBU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[Ivan Pozdeev via Python-Dev]

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

[Jim F.Hilliard]

On Thu, Jul 2, 2020 at 9:51 PM Ethan Furman  wrote:

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

Exactly.

The explanation so far has been that it is not S&W that is a relic of white
supremacy. The Standard English, which it advocates, is. Explaining how
that is would make the commit message sensible, to me at least. (though the
fact that the description of the PR differs from the commit message was
problematic nonetheless.)
___
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/IG5NTJI5KF3247LRRVWI6BNFSOQWVUCU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[Chris Angelico]

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 Re: Recent PEP-8 change (Ivan Pozdeev)

[David Antonini]

No contention to the contrary, but as a routine, post-merge git history 
rewrite, not a grand plan, from what I understand.

Oh the other hand, an 'official' comment on the commit, recognising the issue 
with the original commit message, the following discussion, and any conclusions 
that get reached, might be better, in my opinion. I prefer to recognise and 
critique, rather than erase,
'historical' history, as a rule (as opposed to git history). I think similar 
damage is done in this case, when the record, and opportunity to point to and 
learn from it, is erased.

David

---
Date: Thu, 2 Jul 2020 21:33:56 +0300
From: Ivan Pozdeev 
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:
> 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/ZZKGBAROR7TR2M7TM4EYSIIHXTUBQB4Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[Henk-Jaap Wagenaar]

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] Python Documentation, Python language improvement, and productive discussion

[Carol Willing]

Hi folks,

Earlier this year at the Python Language Summit, Ned Batchelder and I presented 
the concept of a Documentation Workgroup and a vision for the next few years:

- Slidedeck 
https://speakerdeck.com/willingc/cpython-documentation-the-next-5-years
- Blog post 
https://pyfound.blogspot.com/2020/04/cpython-documentation-next-5-years.html

Due to some health issues that I have had the past few months, I haven't yet 
set up the workgroup. It's a priority of mine for July. We will have an open 
call for workgroup participants.

There's a lot going on in the world with COVID19 that is impacting our lives 
directly and indirectly. I encourage the core development community to consider 
how what they share about their feelings on PEP8 may impact others. Clearly, 
this is an issue where it's unlikely that there will be universal agreement. As 
you consider additional posts about PEP8, I encourage you to think about 
whether your post improves the Python language before hitting Send.

Stay safe as we all live together in a world facing unusual constraints due to 
COVID19. 

Warmly,

Carol
___
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/I3M4XZ6EL3FQABBDCGD5HWDARVU7RFPC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Random832]

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".
___
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/ZLFWE2NGCTUJ74FVAZLBIYG3AMTSK3VD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python Documentation, Python language improvement, and productive discussion

[Antoine Pitrou]

On Thu, 02 Jul 2020 20:41:54 -
"Carol Willing"  wrote:
> 
> Earlier this year at the Python Language Summit, Ned Batchelder and I 
> presented the concept of a Documentation Workgroup and a vision for the next 
> few years:
> 
> - Slidedeck 
> https://speakerdeck.com/willingc/cpython-documentation-the-next-5-years
> - Blog post 
> https://pyfound.blogspot.com/2020/04/cpython-documentation-next-5-years.html
> 
> Due to some health issues that I have had the past few months, I haven't yet 
> set up the workgroup. It's a priority of mine for July. We will have an open 
> call for workgroup participants.

Kudos for doing this.  Having a consistent editorial
direction for the documentation is a great idea.

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/36OTCMDX3LILTGWEIQY2KSGML3VZZSDC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Antoine Pitrou]

On Thu, 02 Jul 2020 17:58:44 -0400
Random832  wrote:
> 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?

Because we're talking about PEP 8, and PEP 8 intends to cover the code
style used when writing code in the *Python standard library*.  I don't
think other Python core developers would like to read code with
comments written in French (or, indeed, in Russian or Japanese or...).

We're not talking about third-party projects, which indeed choose
whatever style and language suit them.

Regards

Antoine.

___
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/Z34JMPDRWRVFHNTR4DLPE5THXWDYC7OR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

[Ivan Pozdeev via Python-Dev]

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

---
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:
> 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/ZZKGBAROR7TR2M7TM4EYSIIHXTUBQB4Y/
Code of Conduct: http://python.org/psf/codeofconduct/
--
Regards,
Ivan
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyth

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[Barney Gale]

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

[Random832]

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.
___
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/FA4JMJTR7V745KGMTDK44GUBPE2HNP3V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Nick Coghlan]

On Thu., 2 Jul. 2020, 11:18 am Guido van Rossum,  wrote:

> On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan  wrote:
>
>> The key thing I'm hoping for in PEP 622 itself is that "Syntactic
>> compatibility with a possible future enhancement to assignment
>> statements" be considered as a constraint on the syntax for case
>> patterns.
>>
>
> That would certainly rule out ideas like writing stores as $x or x? or 
> etc., since it would be syntactically incompatible with *current*
> assignment statements.
>

Yeah, having stores be unmarked is perfectly consistent with existing
assignment statements and expressions, so I now think the PEP is correct to
propose that.

However, the two parts of the match lvalue proposal that are a genuine
problem from a syntactic consistency perspective are:

* using "." to mark value constraints (already means attribute binding in
assignment lvalues)
* using "_" to mark wildcard placeholders (already means a normal variable
binding in assignment lvalues)

The conclusion I came to from that observation was that to allow for
potential future syntactic consistency, it isn't variable bindings that
need a symbolic prefix in match lvalues, it's value constraints.

That then leads to the idea of using "?" as a general "value constraint"
marker in match expressions:

* bare "?": wildcard placeholder that allows any value without binding it
* prefix "?": constrains the value in that position without binding it
* infix "?": imposes a value constraint on a value that is being bound to a
name (means the walrus matching pattern is only needed in cases where a
value is being both bound and deconstructed - simple cases would be written
like "name?None" rather than "name:=None")

With this spelling, the named value constraint example from the PEP would
look like this (with an extra case added showing infix value constraints):

===
match color:
case (primary?GREEN, highlights?BLUE):
print("Two tone, huh? Nice!")
case ?BLACK | ?Color.BLACK:
print("Black suits every color")
case BLACK: # This will just assign a new value to BLACK.
...
===

I'll note that adopting this approach would likely mean that "?0", "?None",
etc would qualify as legal value constraints, so a separate decision would
need to be made if it was allowed to omit the prefix for literal
constraints on values that weren't being bound to a name.

A decision would also need to be made on whether the RHS of "?" constraints
was permitted to be a full expression or not (e.g. if function calls were
allowed, I believe there would be significant potential for confusion with
class constraints).

Cheers,
Nick.

>

>
___
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/M5KD3YVIJXLBIXFYN73YUWFCR57KLHAW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Nick Coghlan]

On Fri., 3 Jul. 2020, 2:27 am MRAB,  wrote:

>
> IMHO, the assignment statement should remain as it is, not sometimes
> assign and sometimes not.
>
> There could be another form that does matching:
>
>  try ?x, 0 = (4,5)
>


Huh, this made me wonder if "match/try" may fit people's brains better than
"match/case". I know for me that I want to read case clauses the same way I
would read them in C, which is thoroughly unhelpful.

The following looks weird though, so I don't think I actually like it in
practice:

===
match shape:
try Point(x, y):
...
try Rectangle(x0, y0, x1, y1, painted=True):
...
===

Cheers,
Nick.




>
___
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/H6ZNPMH5T5PY265DGSL7OMSZZH4UDJSJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

[Rémi Lapeyre]

> Le 3 juil. 2020 à 00:32, Ivan Pozdeev via Python-Dev  
> a écrit :
> 
> 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.
> 

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.

___
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/S7FXOUMKFDAD4M76HPDIQ23H5OLHMGX6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

[Eric V. Smith]

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

___
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/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python Documentation, Python language improvement, and productive discussion (Antoine Pitrou)

[David Antonini]

I'm interested in being part of said Docs group!

David


From: python-dev-requ...@python.org 
Sent: Thursday, July 2, 2020 5:33 PM
To: python-dev@python.org 
Subject: Python-Dev Digest, Vol 204, Issue 23

Send Python-Dev mailing list submissions to
python-dev@python.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.python.org/mailman3/lists/python-dev.python.org/
or, via email, send a message with subject or body 'help' to
python-dev-requ...@python.org

You can reach the person managing the list at
python-dev-ow...@python.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-Dev digest..."

Today's Topics:

   1. Re: Python Documentation, Python language improvement, and productive 
discussion
  (Antoine Pitrou)
   2. Re: Recent PEP-8 change (Antoine Pitrou)
   3. Re: Re Re: Recent PEP-8 change (Ivan Pozdeev) (Ivan Pozdeev)


--

Date: Fri, 3 Jul 2020 00:10:04 +0200
From: Antoine Pitrou 
Subject: [Python-Dev] Re: Python Documentation, Python language
improvement, and productive discussion
To: python-dev@python.org
Message-ID: <20200703001004.0fca6c23@fsol>
Content-Type: text/plain; charset=US-ASCII

On Thu, 02 Jul 2020 20:41:54 -
"Carol Willing"  wrote:
>
> Earlier this year at the Python Language Summit, Ned Batchelder and I 
> presented the concept of a Documentation Workgroup and a vision for the next 
> few years:
>
> - Slidedeck 
> https://speakerdeck.com/willingc/cpython-documentation-the-next-5-years
> - Blog post 
> https://pyfound.blogspot.com/2020/04/cpython-documentation-next-5-years.html
>
> Due to some health issues that I have had the past few months, I haven't yet 
> set up the workgroup. It's a priority of mine for July. We will have an open 
> call for workgroup participants.

Kudos for doing this.  Having a consistent editorial
direction for the documentation is a great idea.

Regards

Antoine.


--

Date: Fri, 3 Jul 2020 00:15:29 +0200
From: Antoine Pitrou 
Subject: [Python-Dev] Re: Recent PEP-8 change
To: python-dev@python.org
Message-ID: <20200703001529.2c9ff416@fsol>
Content-Type: text/plain; charset=US-ASCII

On Thu, 02 Jul 2020 17:58:44 -0400
Random832  wrote:
> 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?

Because we're talking about PEP 8, and PEP 8 intends to cover the code
style used when writing code in the *Python standard library*.  I don't
think other Python core developers would like to read code with
comments written in French (or, indeed, in Russian or Japanese or...).

We're not talking about third-party projects, which indeed choose
whatever style and language suit them.

Regards

Antoine.


--

Date: Fri, 3 Jul 2020 01:32:38 +0300
From: Ivan Pozdeev 
Subject: [Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)
To: python-dev@python.org
Message-ID: 
Content-Type: multipart/alternative;
boundary="0905C79342DDD68A7F40BFCF"

This is a multi-part message in MIME format.
--0905C79342DDD68A7F40BFCF
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

At https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge=
, they say that the argument of whether to allow overwriting=20
history in VCSes stems from two opposing views on what a project's histor=
y should be. One is that is shall be a raw, unedited record of=20
events as they happened; the other is that is should be a (polished and a=
dapted for future reading) story of how the project was made.


While I'm firmly in camp story (long story short, it makes history much m=
ore useful for everything except playing the blame game), in this=20
case, there's a case-specific reason, too.


The remarks that stem the controversy have nothing to do with commit's in=
tent in technical terms: clarifying wording that cause=20
misunderstanding. They were simply speculations by the author (and misgui=
ded ones at that since Strunk & White are actually names).


Leaving this commit as it is will leave no trace of any "comment on the c=
ommit" and later discussion to a future onlooker. And as a commit=20
is the official codebase, it will still appear as endorsed by the dev tea=
m. There'd be no clue that this is

[Python-Dev] Re: Recent PEP-8 change

[Antoine Pitrou]

On Thu, 02 Jul 2020 18:54:26 -0400
Random832  wrote:

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

Well, I disagree, at least for documentation where having a consistent
writing style (and it's not only language, but the way things are
presented, structured, etc.) makes for a much more pleasant and
efficient reading experience.

It's not only about being understandable in the basic sense, but in
making comprehension, navigation and information retrieval easy.

Regards

Antoine.

___
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/VCDDHFN4IINY3A4DUOR7G35EAKWJXB7K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Guido van Rossum]

Unfortunately there are millions of ideas. The PEP authors are taking the
dilemma seriously and we are deliberating what to do.

On Thu, Jul 2, 2020 at 4:04 PM Nick Coghlan  wrote:

> On Thu., 2 Jul. 2020, 11:18 am Guido van Rossum,  wrote:
>
>> On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan  wrote:
>>
>>> The key thing I'm hoping for in PEP 622 itself is that "Syntactic
>>> compatibility with a possible future enhancement to assignment
>>> statements" be considered as a constraint on the syntax for case
>>> patterns.
>>>
>>
>> That would certainly rule out ideas like writing stores as $x or x? or
>>  etc., since it would be syntactically incompatible with *current*
>> assignment statements.
>>
>
> Yeah, having stores be unmarked is perfectly consistent with existing
> assignment statements and expressions, so I now think the PEP is correct to
> propose that.
>
> However, the two parts of the match lvalue proposal that are a genuine
> problem from a syntactic consistency perspective are:
>
> * using "." to mark value constraints (already means attribute binding in
> assignment lvalues)
> * using "_" to mark wildcard placeholders (already means a normal variable
> binding in assignment lvalues)
>
> The conclusion I came to from that observation was that to allow for
> potential future syntactic consistency, it isn't variable bindings that
> need a symbolic prefix in match lvalues, it's value constraints.
>
> That then leads to the idea of using "?" as a general "value constraint"
> marker in match expressions:
>
> * bare "?": wildcard placeholder that allows any value without binding it
> * prefix "?": constrains the value in that position without binding it
> * infix "?": imposes a value constraint on a value that is being bound to
> a name (means the walrus matching pattern is only needed in cases where a
> value is being both bound and deconstructed - simple cases would be written
> like "name?None" rather than "name:=None")
>
> With this spelling, the named value constraint example from the PEP would
> look like this (with an extra case added showing infix value constraints):
>
> ===
> match color:
> case (primary?GREEN, highlights?BLUE):
> print("Two tone, huh? Nice!")
> case ?BLACK | ?Color.BLACK:
> print("Black suits every color")
> case BLACK: # This will just assign a new value to BLACK.
> ...
> ===
>
> I'll note that adopting this approach would likely mean that "?0",
> "?None", etc would qualify as legal value constraints, so a separate
> decision would need to be made if it was allowed to omit the prefix for
> literal constraints on values that weren't being bound to a name.
>
> A decision would also need to be made on whether the RHS of "?"
> constraints was permitted to be a full expression or not (e.g. if function
> calls were allowed, I believe there would be significant potential for
> confusion with class constraints).
>
> Cheers,
> Nick.
>
>>
>
>>

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/BWG5N23WBPFDEORGPK43R7N4A6KBRLV6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[Łukasz Langa]

> 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: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Jeff Allen]

On 01/07/2020 21:01, Ethan Furman wrote:

A not-great article, White Fears of Dispossession: Dreyer's English, 
The Elements of Style,and the Racial Mapping of English Discourse, here:


http://radicalteacher.library.pitt.edu/ojs/radicalteacher/issue/view/19/25 



Thanks for posting this. (What a lot of work you must've done to find 
it.) As a result I feel I have a much better understanding of the 
environment in which these thought processes (those displayed in the 
commit message) would be considered rational, even admirable. Food for 
thought.


E. B. White was born in New York -- I believe that's in the northern 
part of the United States, otherwise known as "The North" or the side 
that fought to end slavery.


E. B. White was educated at Cornell.

We should acknowledge that he famously showed an interest in web 
development and invented a sort of mouse. ;-)



Jeff Allen

___
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/STGOKTEBL54YG7NPCLXIFRFJZWL3HQOI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[David Mertz]

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: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[MRAB]

On 2020-07-02 22:17, Jeff Allen wrote:

On 01/07/2020 21:01, Ethan Furman wrote:

A not-great article, White Fears of Dispossession: Dreyer's English, 
The Elements of Style,and the Racial Mapping of English Discourse, here:


http://radicalteacher.library.pitt.edu/ojs/radicalteacher/issue/view/19/25 



Thanks for posting this. (What a lot of work you must've done to find 
it.) As a result I feel I have a much better understanding of the 
environment in which these thought processes (those displayed in the 
commit message) would be considered rational, even admirable. Food for 
thought.


I found the language difficult to understand. For example, "in the midst 
and post the election" instead of "during and after the election". And 
multiply-stacked nouns. And nouns used as verbs. Much like 
"management-speak". If you believe you have something important to say, 
then at least say it clearly.


E. B. White was born in New York -- I believe that's in the northern 
part of the United States, otherwise known as "The North" or the side 
that fought to end slavery.


E. B. White was educated at Cornell.

We should acknowledge that he famously showed an interest in web 
development and invented a sort of mouse. ;-)



___
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/KBX5FZ6VRLYVYRPPBTGCWXLUC27YLAAM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[Chris Angelico]

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: Plan to remove Py_UNICODE APis except PEP 623.

[Richard Damon]

On 7/2/20 10:19 AM, Victor Stinner wrote:
> Do you mean UTF-16 and UTF-32? UTF-16 supports the whole Unicode
> character set but uses the annoying surrogate pairs for characters
> outside the BMP.*

Minor quibble, UTF-16 handles all of the CURRENTLY defined Unicode set,
and there is a currently a promise not to extend Unicode past that, but
at some point they may need to break that promise.

UTF-8, as previously defined (and could be again) easily handles
U+ to U+7FFF.

UTF-16 can handle via the surrogate pairs U+ to U+0010 and
stop there, To extend past that would require some form of heroics,
which is the reason that U+0010 is currently defined as the highest
possible code point, as to allow a higher value breaks UTF-16, and there
currently isn't a desire to do so. At some point in the distant future,
we may run out of 'valid' code points, and this promise will need to be
broken.

UTF-16 grew out of a need to fix what has become UCS-2, which is the
encoding used for earlier Unicode standards, before the need for code
points above U+ (now the BMP) was seen.

-- 
Richard Damon
___
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/HJ7R5Q25EVCSBS7CZFZ5CNYITXOLWWFG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

[Jonathan Goble]

On Thu, Jul 2, 2020 at 7:55 PM Eric V. Smith  wrote:

> But this commit was to the peps repo, which has far fewer commits, one
> branch, no tags, and only 10 PRs. So while it's still an issue, it's not as
> big a deal as if we were talking about the cpython repo.
>
> I don't know how many forks have been made since the commit in question.
>
I don't know about new forks that are just sitting there, but GitHub has a
handy network graph that shows where every fork has diverged from the main
repo: https://github.com/python/peps/network

If you look to the right of the line down to KeanaBerlin on June 26, it
seems that six people have pushed commits to a fork that diverged after
that commit (plus one that committed something to an old fork). That is
based on the time of the commit to the fork, not when it was merged into
the main repo, so it could be fewer, but in any case no more than six
people would need to force-push to their fork(s) if a rewrite was done now.
Also, some of those forks may have already been the subject of PRs that
have been merged, and therefore may be able to be ignored.
___
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/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Stable ABI question.

[Inada Naoki]

On Thu, Jul 2, 2020 at 7:28 PM Victor Stinner  wrote:
>
> Hi,
>
> Last time I looked at PyEval_AcquireLock(), it was used in the wild,
> but I don't recall exactly where, sorry :-( Before removing the
> functions, I suggest to first notify impacted projects of the incoming
> removal, and maybe even propose a fix.

Thank you for suggestion.

I had grepped PyEval_AcquireLock in top4000 packages and I confirmed
it is not used.
But I had not checked PyEval_ReleaseLock because I thought it is used
only pair with PyEval_AcquireLock.

Actually, PyEval_ReleaseLock is used in three packages:

pydevd-pycharm-202.5103.19/pydevd_attach_to_process/windows/attach.cpp
330:DEFINE_PROC(releaseLock, PyEval_Lock*, "PyEval_ReleaseLock", -160);

jep-3.9.0/src/main/c/Jep/pyembed.c
836:PyEval_ReleaseLock();

ptvsd-4.3.2.zip/ptvsd-4.3.2/src/ptvsd/_vendored/pydevd/pydevd_attach_to_process/windows/attach.cpp
330:DEFINE_PROC(releaseLock, PyEval_Lock*, "PyEval_ReleaseLock", -160);


I will keep PyEval_ReleaseLock.

>
> Getting rid of PyEval_AcquireLock() and PyEval_ReleaseLock() in JEP
> doesn't seem trivial. This project uses subinterpreters and uses/used
> daemon threads.
>

I think they use only PyEval_ReleaseLock().  Do they use
PyEval_AcquireLock() too?

Regards,
--
Inada Naoki  
___
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/HMDNL4MC2UMOGRMJ7PVDBWRRFOV7NPAO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Rob Cliffe via Python-Dev]

On 03/07/2020 00:12, Nick Coghlan wrote:
On Fri., 3 Jul. 2020, 2:27 am MRAB, > wrote:



IMHO, the assignment statement should remain as it is, not sometimes
assign and sometimes not.

There could be another form that does matching:

     try ?x, 0 = (4,5)



Huh, this made me wonder if "match/try" may fit people's brains better 
than "match/case". I know for me that I want to read case clauses the 
same way I would read them in C, which is thoroughly unhelpful.


The following looks weird though, so I don't think I actually like it 
in practice:


===
match shape:
    try Point(x, y):
        ...
    try Rectangle(x0, y0, x1, y1, painted=True):
        ...
===

I don't think it looks at all weird in this example, I think it reads 
quite naturally, in my brain at least.

It is maybe not quite so good when comparing with actual values:
    match value:
        try 42:
            ...
        try -1:
            ...
  And it has the virtue of adding one less keyword.


___
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/H6ZNPMH5T5PY265DGSL7OMSZZH4UDJSJ/
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/VFKZX6MGYHZGHL2D2R7HPHCL7F74EQED/
Code of Conduct: http://python.org/psf/codeofconduct/