date:20200703

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

2020-07-03 Thread Paul Moore

On Thu, 2 Jul 2020 at 21:18, David Antonini  wrote:
>
> No contention to the contrary, but as a routine, post-merge git history 
> rewrite, not a grand plan, from what I understand.

David,
When you post, you (or more likely your mail program) somehow adds the
name of the author of the post that you are replying to in parentheses
after the subject. This breaks threading (at least in the GMail web
interface) and is fairly disruptive to following the conversation.
Could you try to stop this happening, please, in the interests of
keeping things more readable?

Thanks,
Paul
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/X3PXNFFICK7YF2KKLB65CBH24PGLZ74U/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Greg Ewing


On 3/07/20 5:37 am, Rhodri James wrote:
It was in Latin 
classes that I learned how sentences are put together, and that's what I 
default to when I'm not thinking hard enough.


For me it's French -- I learned much more about English grammar
while studying French than I ever did from English classes. But
French grammar is a lot closer to English than Latin is, so I
don't usually suffer from much confusion. :-)

--
Greg
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/LBLCDQ6XRT7RDAJK2GI63FUCJNLHQZV3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Federico Salerno


+1

Is there a reason, after all, why we should mark constant patterns as 
special, and not the opposite?



On 02/07/2020 19:10, Walter Dörwald wrote:

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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/BEKMYROEF4E3LXONFU37TDKNWGI6NO4S/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Ivan Pozdeev via Python-Dev

On 03.07.2020 3:10, Łukasz Langa wrote:

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

Formal proposal: Either request a new commit message from the original
author, or have someone rewrite it, and we go ahead and make the
change.

-1

This would be serious precedent to fiddling with publicly replicated repo
history. This would require coordination with project admins as force-pushes
are rightfully disabled for our repositories.

Commit messages aren't usually scrutinized to this extent. If you looked at the
last 1000 commits in cpython, you'd find quite a few with messages that could
be seriously improved. We don't though because commits are immutable. You can
revert them but we never downright replace them with different ones. Otherwise
what's the point in me signing release tags?

Per https://mail.python.org/archives/list/[email protected]/message/T7CM4AUJFQN5WDZ5E4PIR7IIK7AOPRTE/, "commits are immutable" is just
one point of view, as valid as the other one, and leaving this commit as is would be much more harmful than an average poorly-worded one.

Per https://mail.python.org/archives/list/[email protected]/message/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/, we're talking about an infinitely
less impactful peps repo (per https://mail.python.org/archives/list/[email protected]/message/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/, only 6
people in the entire world would be affected).

And, no-one suggested overwriting a Python release, comparing this to that is
blowing it way out of proportion.

Is the commit message perfect? No. Is the intent explained better on the linked
PR? Yes. Is the change itself good? Also yes.

Formal proposal: leave this alone.

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

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/BC5XAXFHEUEIVMD6CUBEV5SJDBR2NAME/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Stable ABI question.

2020-07-03 Thread Victor Stinner

Le ven. 3 juil. 2020 à 04:51, Inada Naoki  a écrit :
> 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.

The PEP 620 doesn't require to keep a deprecated forever: only to
notify projects that the function is going to be removed, and try to
help them to replace it.

pydevd-pycharm


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

I checked with GitHub code search on the JEP project:
PyEval_AcquireLock() is not used.

PyEval_ReleaseLock() is called in a single function:
https://github.com/ninia/jep/blob/639f6cbe512b5ce4b51412564dba8db5bbbf1e3b/src/main/c/Jep/pyembed.c#L835

Also, I'm not sure that JEP uses PyEval_ReleaseLock() properly:
https://github.com/ninia/jep/issues/229#issuecomment-635467616

I don't see why a lock would hold the GIL but release it before exiting.

Maybe JEP should call PyThreadState_DeleteCurrent(), which calls
PyEval_ReleaseLock() internally, in pyembed_thread_close().

The _thread.start_new_thread() calls
_PyThreadState_DeleteCurrent(tstate) when a thread completes, and this
function calls _PyEval_ReleaseLock(tstate).

Maybe PyEval_ReleaseLock() documentation should explain that.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/7M7Z3MZRMKUN4IFRXXQXPZD4KXQCTV7C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Stable ABI question.

2020-07-03 Thread Inada Naoki

On Fri, Jul 3, 2020 at 6:23 PM Victor Stinner  wrote:
>
>
> So it seems possible to fix JEP and pydevd-pycharm. IMHO it's fine to
> remove PyEval_ReleaseLock() in Python 3.10. The deprecation warning is
> there since Python 3.2.
>

While PyEval_AcquireLock is deprecated, PyEval_ReleaseLock is not
deprecated yet in C.
https://github.com/python/cpython/blob/master/Include/ceval.h#L132

Maybe, we can uncomment Py_DEPRECATE in 3.10, and remove it from
header file in 3.12.

Regards,
-- 
Inada Naoki  
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/J7GZBVNTBGCFQPWGN5MRNPE2SE5NNXXE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Stable ABI question.

2020-07-03 Thread Victor Stinner

Le ven. 3 juil. 2020 à 11:19, Victor Stinner  a écrit :
> Le ven. 3 juil. 2020 à 04:51, Inada Naoki  a écrit :
> > 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.
>
> The PEP 620 doesn't require to keep a deprecated forever: only to
> notify projects that the function is going to be removed, and try to
> help them to replace it.
>
> pydevd-pycharm

Oops, I sent the email by mistake while I was typing :-(

pydevd-pycharm doesn't *need* PyEval_ReleaseLock() on Python 3.10: it
only uses PyEval_ReleaseLock() on Python 3.1 and older!

 if (version >= PythonVersion_32) {
 // we will release the GIL here
gilRelease(gilState);
 } else {
 releaseLock();
 }

Maybe it's time for pydevd-pycharm to remove support for Python 2.7.
Or the code can be made optional using "#if PY_VERSION_HEX <
0x0302".

So it seems possible to fix JEP and pydevd-pycharm. IMHO it's fine to
remove PyEval_ReleaseLock() in Python 3.10. The deprecation warning is
there since Python 3.2.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/CENAKUYFY6BQFVDCUWMDZW6LAWD5UH24/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Stable ABI question.

2020-07-03 Thread Victor Stinner

PyEval_ReleaseLock() is deprecated since Python 3.2 in the documentation:
https://docs.python.org/dev/c-api/init.html#c.PyEval_ReleaseLock

PyEval_AcquireLock() was annotated with Py_DEPRECATED() by Serhiy
Storchaka in https://bugs.python.org/issue19569#msg280110 where he
wrote:

"PyEval_ReleaseLock() is used in Python/pystate.c. It can't be
replaced with PyEval_ReleaseThread() since the latter don't accept
NULL."

I wrote in a previous email, I modified Python internals to no longer
call PyEval_ReleaseLock(), but a new internal
_PyEval_ReleaseLock(tstate) function instead.

Maybe we can still mark PyEval_ReleaseLock() as deprecated in Python
3.9, since it's just compiler warning, it's less intrusive than a
warning emitted at runtime.

Victor

Le ven. 3 juil. 2020 à 11:28, Inada Naoki  a écrit :
>
> On Fri, Jul 3, 2020 at 6:23 PM Victor Stinner  wrote:
> >
> >
> > So it seems possible to fix JEP and pydevd-pycharm. IMHO it's fine to
> > remove PyEval_ReleaseLock() in Python 3.10. The deprecation warning is
> > there since Python 3.2.
> >
>
> While PyEval_AcquireLock is deprecated, PyEval_ReleaseLock is not
> deprecated yet in C.
> https://github.com/python/cpython/blob/master/Include/ceval.h#L132
>
> Maybe, we can uncomment Py_DEPRECATE in 3.10, and remove it from
> header file in 3.12.
>
> Regards,
> --
> Inada Naoki  



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/OSGWHNO2N2E4YN7JJDZ3YA5VUVKB6MIE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Greg Ewing


On 3/07/20 5:09 am, David Mertz wrote:
"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.


Maybe the indeterminate use of "he" was influenced by French?
In French there are no neutral pronouns at all, and the masculine
ones are used for indeterminate and mixed genders.

--
Greg
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/NPGBXCZMPJWR277OYXRDB7S4L6Z7IIIC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Stable ABI question.

2020-07-03 Thread Serhiy Storchaka


03.07.20 12:34, Victor Stinner пише:

PyEval_ReleaseLock() is deprecated since Python 3.2 in the documentation:
https://docs.python.org/dev/c-api/init.html#c.PyEval_ReleaseLock

PyEval_AcquireLock() was annotated with Py_DEPRECATED() by Serhiy
Storchaka in https://bugs.python.org/issue19569#msg280110 where he
wrote:

"PyEval_ReleaseLock() is used in Python/pystate.c. It can't be
replaced with PyEval_ReleaseThread() since the latter don't accept
NULL."

I wrote in a previous email, I modified Python internals to no longer
call PyEval_ReleaseLock(), but a new internal
_PyEval_ReleaseLock(tstate) function instead.

Maybe we can still mark PyEval_ReleaseLock() as deprecated in Python
3.9, since it's just compiler warning, it's less intrusive than a
warning emitted at runtime.


+1 for adding Py_DEPRECATED() in 3.9.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2XICLNP5L7GW7GOX7C3CNX7OGEWYYM3Y/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Henk-Jaap Wagenaar

On Fri, 3 Jul 2020 at 08:50, Ivan Pozdeev via Python-Dev <
[email protected]> wrote:

>
> Per
> https://mail.python.org/archives/list/[email protected]/message/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/,
> we're talking about an infinitely
> less impactful peps repo (per
> https://mail.python.org/archives/list/[email protected]/message/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/,
> only 6
> people in the entire world would be affected).
>
>
It will not affect only 6 people.

That is just the number of people who have forks that we know about and
even those who do not have forks but maintain a copy (for whatever reason)
of the main branch will be affected: they will have to reset their branch
or do some other malarkey to get this new "improved" history. This will be
a much bigger group of people and also potentially software solutions that
are mirroring the repo for one reason or another.

That's one of the prices you pay (or I would say benefit) for having a
decentralized version control system: it makes it hard to rewrite
(supposedly "improve") history.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ICEY5RDK7P7VWDXH7W6JI76SO57JZB4I/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Ivan Pozdeev via Python-Dev



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

On Fri, 3 Jul 2020 at 08:50, Ivan Pozdeev via Python-Dev mailto:[email protected]>> wrote:


Per 
https://mail.python.org/archives/list/[email protected]/message/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/,
 we're talking about an
infinitely
less impactful peps repo (per 
https://mail.python.org/archives/list/[email protected]/message/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/,
only 6
people in the entire world would be affected).


It will not affect only 6 people.

That is just the number of people who have forks that we know about and even those who do not have forks but maintain a copy (for whatever 
reason) of the main branch will be affected: they will have to reset their branch or do some other malarkey to get this new "improved" 
history. This will be a much bigger group of people and also potentially software solutions that are mirroring the repo for one reason or 
another.


That's one of the prices you pay (or I would say benefit) for having a decentralized version control system: it makes it hard to rewrite 
(supposedly "improve") history.


So what? They'll have to synchronise their history to ours to be able to make a PR. And if they don't, it doesn't matter for us what they do 
with the data anyway since they are responsible for maintaining it and keeping it relevant if they need to, not us.


Plus, since it's the PEPs repo, it's tightly bould to the Python project -- the 
usefulness of a fork disconnected from it is pretty low.


--
Regards,
Ivan
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/WIUPJNTWRHJHJR6AMPKXCWT4F4K4IJQF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Rhodri James


On 03/07/2020 01:10, Łukasz Langa wrote:

Commit messages aren't usually scrutinized to this extent.


Commit messages are usually political statements.


Formal proposal: leave this alone.


-1.  Simply by having it in the repository, the statement implicitly has 
the support of the Python community (more specifically the Steering 
Council).  Given the manifest controversy, leaving it alone is... a 
brave decision, minister[*]


[*] See the original UK TV series "Yes, Minister" and "Yes, Prime 
Minister".  The senior civil servant praises his minister for making a 
"brave decision" when he wants to point out consequences the minister 
won't like.


--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/7CZMBZUCD4VV3RQPFC3CNZTP7RVDWYRZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Henk-Jaap Wagenaar

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

> So what?
>
Unnecessary

> They'll have to synchronise their history to ours to be able to make a PR.
> And if they don't, it doesn't matter for us what they do with the data
> anyway since they are responsible for maintaining it and keeping it
> relevant if they need to, not us
>
That is not a very collaborative mindset.

Can somebody give an example of when we force-pushed before? Surely there
should be a PEP outlining when we force push and how we communicate this to
our "consumers" before/when we do so?

> Plus, since it's the PEPs repo, it's tightly bould to the Python project
> -- the usefulness of a fork disconnected from it is pretty low.
>

It partially serves as documentation for the Python project, so mirroring
it and its documentation (in git form or in its presented form) can
definitely have a use, for example, if you are an environment that has no
internet access (common in secret government work, and I am sure their IT
team will be even less pleased that they have to do something by hand and
overwrite history!).

>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/55F6YYVAHRRIGUCXZQWZNUKK3LSDDNYZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

2020-07-03 Thread Rhodri James


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'm actually surprised at how much I like that.  It certainly gets me 
out of the C mindset and makes it easier for me to recognise that 
Point(x,y) isn't an instantiation.


--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/R32T63WXY3ILFKSMISY3KIKA7LUGBKZC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Ivan Pozdeev via Python-Dev



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

On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev mailto:[email protected]>> wrote:

So what?

Unnecessary

They'll have to synchronise their history to ours to be able to make a PR. 
And if they don't, it doesn't matter for us what they do
with the data anyway since they are responsible for maintaining it and 
keeping it relevant if they need to, not us

That is not a very collaborative mindset.


I fail to see how. We provide all the tools to collaborate. If a person has a divergent history, they will see that when trying to 
collaborate (submit a PR or otherwise interact with our repo from theirs in any way) and will be able to fix that problem then and there.




Can somebody give an example of when we force-pushed before? Surely there should be a PEP outlining when we force push and how we 
communicate this to our "consumers" before/when we do so?


Plus, since it's the PEPs repo, it's tightly bould to the Python project -- 
the usefulness of a fork disconnected from it is pretty low.


It partially serves as documentation for the Python project, so mirroring it and its documentation (in git form or in its presented form) 
can definitely have a use, for example, if you are an environment that has no internet access (common in secret government work, and I am 
sure their IT team will be even less pleased that they have to do something by hand and overwrite history!).


--
Regards,
Ivan
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/4MQYGI44AZT66SOHZDDYQVQXZBZTNEEU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Chris Angelico

On Fri, Jul 3, 2020 at 11:03 PM Ivan Pozdeev via Python-Dev
 wrote:
>
>
> On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote:
>
> On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev  wrote:
>>
>> So what?
>
> Unnecessary
>>
>> They'll have to synchronise their history to ours to be able to make a PR. 
>> And if they don't, it doesn't matter for us what they do with the data 
>> anyway since they are responsible for maintaining it and keeping it relevant 
>> if they need to, not us
>
> That is not a very collaborative mindset.
>
>
> I fail to see how. We provide all the tools to collaborate. If a person has a 
> divergent history, they will see that when trying to collaborate (submit a PR 
> or otherwise interact with our repo from theirs in any way) and will be able 
> to fix that problem then and there.
>
>
> Can somebody give an example of when we force-pushed before? Surely there 
> should be a PEP outlining when we force push and how we communicate this to 
> our "consumers" before/when we do so?
>

Even if someone isn't aware of the change, the PEPs repo *already*
rewrites commits as they get merged, so any discrepancies would be
papered over cleanly. Consider:

https://github.com/python/peps/pull/1488
Two commits in the pull request

https://github.com/python/peps/commit/045450aaf47941f3ee7daaa1774947b31885b2aa
One commit in the final repo.

If someone has the old version of the repo and creates a pull request,
we'll just squash all the differences down and create a single commit
that does the intent in a cleaner way. The only real effect will be a
bit of noise during the PR process itself.

There has ALREADY been far more hassle resulting from this commit
message than there would be from a force-push.

ChrisA
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/W3UOLWJZHRLJA75PJZ5O434FPPLBZMLQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Henk-Jaap Wagenaar

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

> On Fri, Jul 3, 2020 at 11:03 PM Ivan Pozdeev via Python-Dev
>  wrote:
> >
> >
> > On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote:
> >
> > On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev  wrote:
> >>
> >> So what?
> >
> > Unnecessary
> >>
> >> They'll have to synchronise their history to ours to be able to make a
> PR. And if they don't, it doesn't matter for us what they do with the data
> anyway since they are responsible for maintaining it and keeping it
> relevant if they need to, not us
> >
> > That is not a very collaborative mindset.
> >
> >
> > I fail to see how. We provide all the tools to collaborate. If a person
> has a divergent history, they will see that when trying to collaborate
> (submit a PR or otherwise interact with our repo from theirs in any way)
> and will be able to fix that problem then and there.
> >
> >
> > Can somebody give an example of when we force-pushed before? Surely
> there should be a PEP outlining when we force push and how we communicate
> this to our "consumers" before/when we do so?
> >
>
> Even if someone isn't aware of the change, the PEPs repo *already*
> rewrites commits as they get merged,


That is not the right way of putting it in my opinion. What you describe
below is rewriting commits when merging/completing a pull request
(squashing is common). That is very different to going back to a commit
that is already in the same branch and rewriting that.


> so any discrepancies would be
> papered over cleanly. Consider:
>
> https://github.com/python/peps/pull/1488
> Two commits in the pull request
>
>
> https://github.com/python/peps/commit/045450aaf47941f3ee7daaa1774947b31885b2aa
> One commit in the final repo.
>
> If someone has the old version of the repo and creates a pull request,
> we'll just squash all the differences down and create a single commit
> that does the intent in a cleaner way. The only real effect will be a
> bit of noise during the PR process itself.
>
> There has ALREADY been far more hassle resulting from this commit
> message than there would be from a force-push.
>

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


>
> ChrisA
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/W3UOLWJZHRLJA75PJZ5O434FPPLBZMLQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/PG7U3HQOCQVMQFUQ5CPGGX5F4FIV3MHP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: When can we remove wchar_t* cache from string?

2020-07-03 Thread Victor Stinner

Le sam. 13 juin 2020 à 12:39, Inada Naoki  a écrit :
> Of course, there is an API to create an empty string: PyUnicode_New(0, 0);
> But since Cython is using `PyUnicode_FromString(NULL, 0)`,
> keep it working for some versions will mitigate the breaking change.
> Note that we can remove wchar_t cache while keeping it working.
>
> Anyway, this is an idea for mitigation.  If all of maintained packages fixes 
> it
> before Python 3.11, mitigation is not needed.

Can someone propose a Cython PR to use PyUnicode_New(0, 0) on Python
3.3 and newer, or PyUnicode_FromString(NULL, 0) on old Python
versions?

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/KMMWVNPWPIYVCTASWFHP5CXQZWWGR5Y2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: When can we remove wchar_t* cache from string?

2020-07-03 Thread Victor Stinner

Sorry, ignore my comment: Cython no longer uses
PyUnicode_FromString(NULL, 0) in the master branch. The change was
backported to the 0.29.x branch, but this stable branch requires a
second fix, so I wrote it:
https://github.com/cython/cython/pull/3721

Victor

Le ven. 3 juil. 2020 à 16:00, Victor Stinner  a écrit :
>
> Le sam. 13 juin 2020 à 12:39, Inada Naoki  a écrit :
> > Of course, there is an API to create an empty string: PyUnicode_New(0, 0);
> > But since Cython is using `PyUnicode_FromString(NULL, 0)`,
> > keep it working for some versions will mitigate the breaking change.
> > Note that we can remove wchar_t cache while keeping it working.
> >
> > Anyway, this is an idea for mitigation.  If all of maintained packages 
> > fixes it
> > before Python 3.11, mitigation is not needed.
>
> Can someone propose a Cython PR to use PyUnicode_New(0, 0) on Python
> 3.3 and newer, or PyUnicode_FromString(NULL, 0) on old Python
> versions?
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/WJNIG4VY32DJUYPTK3GPIE2VKG4DDZEQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 622 railroaded through?

2020-07-03 Thread Rob Cliffe via Python-Dev

Whoa!

I have an uneasy feeling about this PEP.

AFAIK the usual procedure for adding a new feature to Python is:
An idea is raised and attracts some support.
Someone sufficiently motivated writes a PEP.
The PEP is thoroughly discussed.
Eventually a consensus (or at least an "agree to differ" stalemate)
is reached.

The PEP is accepted (if it is).
(Then and only then) Someone works on the implementation.
etc.

However, PEP 622 only seems to have been presented to the Python
community only *after* a well-developed (if not finalised)
implementation was built. A fait accompli. So there will inevitably be
resistance from the developers to accept changes suggested on
python-dev. And since the PEP has Guido's authority behind it, I think
it is likely that it will eventually be accepted pretty much as it was
originally written.
This means that most of the discussion we have seen on python-dev (and
there has been a lot) will end up being just pissing in the wind. (I
don't mean to be vulgar or disrespectful; I just can't think of another
phrase that conveys my meaning so well.) And Guido's 2nd email ("PEP
622: Structural Pattern Matching -- followup") already to me (YMMV)
reads rather like "OK, you've had your fun, now try not to joggle our
elbows too much while we get on with the work".

I don't know how many of the decisions made in the PEP are right and how
many could be improved (it is of course a subjective question anyway).
I do think it's a pity that the Python community did not have the chance
to supply feedback earlier down the road (when IMO it would have been
taken more seriously).
While Guido and the other developers have obviously already put a huge
amount of work into this PEP (and by now probably have a significant
emotional investment in it), I do hope that they will take the time to
consider seriously and on their merits most/all suggested changes,
rather than being tempted to rush through the acceptance and
implementation of the PEP.

Best wishes
Rob Cliffe
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/IG4VNKZF4J7OR3L665PE26KL7L6SFQSQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 railroaded through?

2020-07-03 Thread Chris Angelico

On Sat, Jul 4, 2020 at 12:48 AM Rob Cliffe via Python-Dev
 wrote:
>
> Whoa!
>
> I have an uneasy feeling about this PEP.
>
> AFAIK the usual procedure for adding a new feature to Python is:
>  An idea is raised and attracts some support.
>  Someone sufficiently motivated writes a PEP.
>  The PEP is thoroughly discussed.
>  Eventually a consensus (or at least an "agree to differ" stalemate)
> is reached.
>  The PEP is accepted (if it is).
>  (Then and only then) Someone works on the implementation.
>  etc.
>
> However, PEP 622 only seems to have been presented to the Python
> community only *after* a well-developed (if not finalised)
> implementation was built.  A fait accompli.

The PEP is still a draft and has not been accepted. Don't worry, the
normal process is still happening :)

Having a reference implementation is a HUGE help, because people can
play around with it. There's a fork running an interactive playground
so you can go right now and get a feel for the way the syntax works.

The implementation has *not* been merged into the CPython trunk. It's
not a fait accompli - it's a tool to help people evaluate the proposal
(and all of the different variants of the proposal as it evolves).

Speaking with my PEP Editor hat on, I would be *thrilled* if more
proposals came with ready-to-try code. Only a very few have that
luxury, and a lot of the debating happens with nothing but theory -
people consider what they *think* they'd do, without actually being
able to try it out and see if it really does what they expect. Having
a reference implementation isn't necessary, of course, but it's
definitely a benefit and not a downside. Also, there HAVE been
proposals with full reference implementations that have ended up
getting rejected; it's not a guarantee that it'll end up getting
merged.

Hope that lessens your fears a bit :)

ChrisA
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/E5U5Z6RRWSWHGXTZEQ6CBPORVXS3CPWD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 railroaded through?

2020-07-03 Thread Antoine Pitrou

On Wed, 1 Jul 2020 21:14:00 +0100
Rob Cliffe via Python-Dev  wrote:
> Whoa!
> 
> I have an uneasy feeling about this PEP.
> 
> AFAIK the usual procedure for adding a new feature to Python is:
>      An idea is raised and attracts some support.
>      Someone sufficiently motivated writes a PEP.
>      The PEP is thoroughly discussed.
>      Eventually a consensus (or at least an "agree to differ" stalemate) 
> is reached.
>      The PEP is accepted (if it is).
>      (Then and only then) Someone works on the implementation.
>          etc.
> 
> However, PEP 622 only seems to have been presented to the Python 
> community only *after* a well-developed (if not finalised) 
> implementation was built.  A fait accompli.

I think what you describe as "the usual procedure" isn't as usual as
you think.  For example, when I wrote PEP 442 (Safe object
finalization), I don't remember a preliminary round of raising support
for the idea.  I had that idea in mind after repeated frustration with
the previous finalization semantics, attempted writing an implementation
which ended up functional, and then wrote a PEP from it.

That said, PEP 622 is a much broader PEP adding a whole new syntactical
feature with unusual semantics attached to it, so it's conceivable to
be more cautious with the discussion process.

Regards

Antoine.

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/IGDMVG6N5U4I76YH6SUWGS5Q4XDE3OT6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Jim J. Jewett

If the writing is less formal (and I think most comments and even most 
documentation is somewhat informal), you can sometimes just address the reader 
directly, as "you".

For the most formal writing most people will ever encounter, one can use "one" 
as the singular pronoun of indeterminate gender.  Alas, I suspect "one" 
confuses as many people as a singular "they"; in additional to grammatical 
confusion ("one *what*?"), the formality itself can be a barrier to students 
who are feeling overwhelmed.  The passive voice also has a tendency to creep in 
more with use of "one."

I'm personally fine with singular they, unless the context is very formal.  I 
personally prefer to remedy that confusion by using a less formal style.  The 
people I've met who had genuine and lasting difficulty with singular "they" 
even in informal contexts were ... at a stage of life where they were unlikely 
to take up new hobbies as intricate as programming.

-jJ
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/E6ISOWT4FEQRZVTQ7TWYSEBFTB6ORT7E/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Jim J. Jewett

The biggest problem with this is figuring out when to switch.  If you switch 
within a single example, you will confuse many readers.  If you have a series 
of related examples, people will disagree about when it is reasonable to 
substitute a new person.  

Using specific personal names (Alice and Bob are traditional) for each 
character can help with that, but it is still a problem.  And using personal 
names brings up an cultural issues more directly than "Strunk and White" would. 
 (If Bob and Alice seem neutral to you, would you do a double-take on Kehinde 
or Oladotun?)
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/TCXKCMYVARE5EJLHOA6J5X5LBV5CTX6Z/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Jim J. Jewett

Specifying British English (as opposed to just British spelling) would probably 
tempt people to use more Brit-only idioms, in the same way that Monty Python 
tempts people to make Flying Circus references.

I don't love the idea of talking more about how many zeroes in a billion, or 
whether "table it" is an extra-fun reference *because* of the ambiguity.

-jJ
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/KAY3WEL7XTG6527FM2HSA747D2T27T6E/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread MRAB


On 2020-07-03 17:52, Jim J. Jewett wrote:

Specifying British English (as opposed to just British spelling) would probably 
tempt people to use more Brit-only idioms, in the same way that Monty Python 
tempts people to make Flying Circus references.

I don't love the idea of talking more about how many zeroes in a billion, or whether 
"table it" is an extra-fun reference *because* of the ambiguity.


The UK officially switched to the "short" billion (9 zeros) in 1974.

See: https://en.wikipedia.org/wiki/Billion
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/PEFPBAMWAFW4VVZAKSD2O2PDJ6OEZH7B/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Steven D'Aprano

On Thu, Jul 02, 2020 at 12:47:07PM -0400, Piper Thunstrom wrote:

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

You are oversimplifying the situation.

It is mostly American grammarians who rail against it, so please don't 
impose American cultural experiences and values on the rest of the 
English-speaking world.

In terms of modern English *vernacular* (i.e. common speech), singular- 
they has never really gone out of fashion despite the protests of some 
grammarians, not even in the USA. For instance Green (1977) reported 
that singular-they was the "normal" third-person singular generic 
pronoun among junior college students, and Meyers (1990) found that 52% 
of college students used it. (Interestingly, she found that male 
students used singular-they slightly more often than female students.)

https://sci-hub.tw/10.2307/455911

The 1996 edition of "The New Fowler’s Dictionary of Modern English 
Usage" dismissed objections to singular-they, and observed that it is 
"passing unnoticed" by standard (British) English speakers and copy 
editors. Likewise the 1998 edition of "The New Oxford Dictionary of 
English" used the form in their definitions.

https://public.oed.com/blog/a-brief-history-of-singular-they/

Even in the USA, the record has been mixed. For example, President 
George Bush's 1991 State of the Union Address used it:

"If anyone tells you that America's best days are behind her, then 
they're looking the wrong way."

and as far as I can tell, it passed without comment at the time.

Garner's Modern American Usage (2003) recommended cautious use of 
singular-they; the 1993 edition of The Chicago Manual of Style 
explicitly recommended singular-they, (alas, the following edition 
backpedalled somewhat, suggesting that it was fine in casual writing 
but not formal writing).

Even Webster's Dictionary Of Common English (1989) described it as "in 
common standard use".

While the popularity of singular-they has certainly waxed and waned 
over the centuries, it was in common use at least back in the 1970s and 
1980s, e.g. see the citations here:

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4293036/

-- 
Steven
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/SZB5SNYLG6D4H3SWYI5B4DPWIMLQ57HE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

2020-07-03 Thread Python tracker


ACTIVITY SUMMARY (2020-06-26 - 2020-07-03)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7520 (+30)
  closed 45424 (+44)
  total  52944 (+74)

Open issues with patches: 3042 


Issues opened (54)
==

#41004: Hash collisions in IPv4Interface and IPv6Interface
https://bugs.python.org/issue41004  reopened by corona10

#41129: Python extension modules fail to build on Mac 10.15.1 (Catalin
https://bugs.python.org/issue41129  opened by andrewfg1992

#41130: Improve/fix FreeBSD Bluetooth socket support
https://bugs.python.org/issue41130  opened by myfreeweb

#41131: Augment random.choices() with the alias method
https://bugs.python.org/issue41131  opened by rhettinger

#41133: Insufficient description of cyclic garbage collector for C API
https://bugs.python.org/issue41133  opened by iabervon

#41134: distutils.dir_util.copy_tree FileExistsError when updating sym
https://bugs.python.org/issue41134  opened by Tom Hale

#41135: Suggested change to http.server.HTTPServer to prevent socket r
https://bugs.python.org/issue41135  opened by Michael Rich

#41136: argparse uses default encoding when read arguments from file
https://bugs.python.org/issue41136  opened by serhiy.storchaka

#41137: pdb uses the locale encoding for .pdbrc
https://bugs.python.org/issue41137  opened by serhiy.storchaka

#41138: trace CLI reads source files using the locale encoding
https://bugs.python.org/issue41138  opened by serhiy.storchaka

#41139: cgi uses the locale encoding for log files
https://bugs.python.org/issue41139  opened by serhiy.storchaka

#41140: cgitb uses the locale encoding for log files
https://bugs.python.org/issue41140  opened by serhiy.storchaka

#41141: remove unneeded handling of '.' and '..' from patlib.Path.iter
https://bugs.python.org/issue41141  opened by sir-sigurd

#41143: distutils uses the locale encoding for the .pypirc file
https://bugs.python.org/issue41143  opened by serhiy.storchaka

#41145: EmailMessage.as_string is altering the message state and actua
https://bugs.python.org/issue41145  opened by mardiros

#41146: Convert signal.default_int_handler() to Argument Clinic
https://bugs.python.org/issue41146  opened by serhiy.storchaka

#41147: Document that redirect_std{out,err} yield the new stream as th
https://bugs.python.org/issue41147  opened by PeterJCLaw

#41148: IDLE uses the locale encoding for config files
https://bugs.python.org/issue41148  opened by serhiy.storchaka

#41149: Threads can fail to start
https://bugs.python.org/issue41149  opened by Barney Stratford

#41150: pipes uses text files and the locale encodig
https://bugs.python.org/issue41150  opened by serhiy.storchaka

#41151: Support for new Windows pseudoterminals in the subprocess modu
https://bugs.python.org/issue41151  opened by njs

#41154: test_pkgutil:test_name_resolution fails on some platforms
https://bugs.python.org/issue41154  opened by RJ722

#41157: email.message_from_string() is unable to find the headers for 
https://bugs.python.org/issue41157  opened by jpatel

#41160: Cross-compiling for GNU/Hurd fails
https://bugs.python.org/issue41160  opened by mbakke

#41162: Clear audit hooks after destructors
https://bugs.python.org/issue41162  opened by steve.dower

#41163: test_weakref hangs
https://bugs.python.org/issue41163  opened by Peter KuÅ¥Ã¡k

#41165: [Python 3.10] Remove APIs deprecated long enough
https://bugs.python.org/issue41165  opened by inada.naoki

#41167: Add new formats to PyArg_ParseTuple for "str or None"
https://bugs.python.org/issue41167  opened by inada.naoki

#41168: Lack of proper checking in PyObject_SetAttr leads to segmentat
https://bugs.python.org/issue41168  opened by Iman Sharafodin

#41169: socket.inet_pton raised when pass an IPv6 address like "[::]" 
https://bugs.python.org/issue41169  opened by seahoh

#41170: Use strnlen instead of strlen when the size i known.
https://bugs.python.org/issue41170  opened by Niclas Larsson

#41171: Create companion methods of "PyType_FromSpec*" to allow settin
https://bugs.python.org/issue41171  opened by WildCard65

#41172: test_peg_generator C tests fail on Windows ARM
https://bugs.python.org/issue41172  opened by steve.dower

#41173: Windows ARM buildbots cannot upload results
https://bugs.python.org/issue41173  opened by steve.dower

#41174: asyncio.coroutine decorator returns a non-generator function w
https://bugs.python.org/issue41174  opened by a-feld

#41175: Static analysis issues reported by GCC 10
https://bugs.python.org/issue41175  opened by cstratak

#41176: revise Tkinter mainloop dispatching flag behavior
https://bugs.python.org/issue41176  opened by Richard Sheridan

#41177: ConvertingList and ConvertingTuple lack iterators and Converti
https://bugs.python.org/issue41177  opened by godot_gildor

#41178: Registry writes on Windows Store - workaround
https://bugs.python.org/issue41178  opene

[Python-Dev] Re: Flexible assignment targets

2020-07-03 Thread Terry Reedy


On 7/3/2020 8:28 AM, Rhodri James wrote:

On 03/07/2020 00:12, Nick Coghlan wrote:

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



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


I'm actually surprised at how much I like that.  It certainly gets me 
out of the C mindset and makes it easier for me to recognise that 
Point(x,y) isn't an instantiation.


I really like the verb subclause.  A match statement *tries* to match an 
object to sequence of pattern options, accepting the first structure 
match.  In C, the cases are values (bit patterns) and the matching is by 
'equals'.  For the proposed matching, equality is the trivial pattern 
match, but generally, a more complicated action is required.  I have the 
impression that at least some match action failures could be detected by 
a caught exception, as in "try: x,y = obj" to see if obj matches pattern 
'x,y'.  Since exceptions are ignored, try: clauses may bee followed by 
another try: clause to try another pattern.



--
Terry Jan Reedy

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2ZS4ZU4LPATRAHDHOSEJIWWMUXWZEY5H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 railroaded through?

2020-07-03 Thread Simon Cross

On Fri, Jul 3, 2020 at 4:42 PM Rob Cliffe via Python-Dev <
[email protected]> wrote:

> And since the PEP has Guido's authority behind it, I think
> it is likely that it will eventually be accepted pretty much as it was
> originally written.
>

This seems a bit unfair to Guido. He seems to put a lot of effort into
taking onboard feedback and I would prefer it if the community encouraged
long term contributors to keep contributing, rather than suggesting that
this was somehow problematic (of course new contributors are good too, as
are new-and-old contributors working together).

Full disclosure: I'm not a huge fan of this PEP myself -- it seems to add a
lot of new syntax to support a coding idiom that I consider an anti-pattern
-- but others seem to have raised similar points to mine, so I think my
point of view has already been fairly well represented in the discussion.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/YCLL5H7NYKUEEBTQHPQSRQANV5JKFAQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 railroaded through?

2020-07-03 Thread Eric Snow

On Fri, Jul 3, 2020, 09:18 Antoine Pitrou  wrote:

> I think what you describe as "the usual procedure" isn't as usual as
> you think.
>

+1

Also,  keep in mind that PEPs are a tool for the decision maker (i.e. BDFL
delegate).  Effectively, everything else is convention.  The process
usually involves community feedback, but has never been community-driven.
All this has become more painful for volunteers as the Python community has
grown.

-eric

>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/QUFB5NI64ASIESOCWHNPUQZPR5BEMXQF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 railroaded through?

2020-07-03 Thread Eric Snow

On Fri, Jul 3, 2020, 12:40 Eric Snow  wrote:

> Also,  keep in mind that PEPs are a tool for the decision maker (i.e.
> BDFL delegate).  Effectively, everything else is convention.  The process
> usually involves community feedback, but has never been community-driven.
> All this has become more painful for volunteers as the Python community has
> grown.
>
> -eric
>

To further elaborate on that, a PEP isn't legislation to be approved by the
community.  Rather, it is meant to capture the proposal and discussion
sufficiently that the BDFL/delegate can make a good decision.  Ultimately
there isn't much more to the process than that, beyond convention.  The
BDFL-delegate is trusted to do the right thing and the steering council is
there as a backstop.

It's up to the decision maker to reach a conclusion and it makes sense that
they especially consider community impact.  However, there is no
requirement of community approval.  This is not new.  Over the years quite
a few decisions by Guido (as BDFL) sparked controversy yet in hindsight
Python is better for each of those decisions.  (See PEP 20.)

The main difference in recent years is the growth of the Python community,
which is a happy problem even if a complex one. :)  There has been a huge
influx of folks without context on Python's governance but with contrary
expectations and loud voices.  On the downside, growth has greatly
increased communications traffic and signal-to-noise, as well as somewhat
shifting tone in the wrong direction.  Unfortunately all this contributed
to us losing our BDFL. :(  Thankfully we have the steering council as a
replacement.

Regardless, Python is not run as a democracy nor by a representative body.
Instead, this is a group of trusted volunteers that are trying their best
to keep Python going and make it better.  The sacrifices they make reflect
how much they care about the language and the community, especially as
dissenting voices increase in volume and vitriol.  That negativity has a
real impact.

-eric

>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/GTOD2OHTIJU34DQS6XH756X4K2FLL2C2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Stable ABI question.

2020-07-03 Thread Brett Cannon

On Thu, Jul 2, 2020 at 8:05 PM Inada Naoki  wrote:

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

As the dev manager for ptvsd I can officially tell not to worry about it as
the project has been superseded by debugpy.

-Brett


>
>
> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/HMDNL4MC2UMOGRMJ7PVDBWRRFOV7NPAO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/QJN4S6OTOOE3ZFQSWKJV6CSGX77THEDE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 railroaded through?

2020-07-03 Thread Brett Cannon

On Fri, Jul 3, 2020 at 7:39 AM Rob Cliffe via Python-Dev <
[email protected]> wrote:

> Whoa!
>
> I have an uneasy feeling about this PEP.
>
> AFAIK the usual procedure for adding a new feature to Python is:
>  An idea is raised and attracts some support.
>  Someone sufficiently motivated writes a PEP.
>  The PEP is thoroughly discussed.
>  Eventually a consensus (or at least an "agree to differ" stalemate)
> is reached.
>  The PEP is accepted (if it is).
>  (Then and only then) Someone works on the implementation.
>

That "then and only then" part is not correct. It just happens to be
typical due to people wanting to see if their idea has any support before
putting in the effort to actually code it up. Personally I sometimes wonder
if we should require a proof-of-concept upfront for all PEPs that introduce
a code change.

>  etc.
>
> However, PEP 622 only seems to have been presented to the Python
> community only *after* a well-developed (if not finalised)
> implementation was built.  A fait accompli.  So there will inevitably be
> resistance from the developers to accept changes suggested on
> python-dev.

Then that's on them. But it may backfire if people don't like what there
PEP is presenting.

>   And since the PEP has Guido's authority behind it, I think
> it is likely that it will eventually be accepted pretty much as it was
> originally written.
>

I'm trying to not take that as an insult, but I will say the steering
council does not rubber stamp Guido's PEPs. We do debate them and consider
them like any other PEP. It's not our fault he has a good sense of design
even in retirement. 😉 So as usual, once this PEP is ready for
consideration (which it isn't as stated by the PEP authors), we will
consider it like any other PEP that tries to change the language.

> This means that most of the discussion we have seen on python-dev (and
> there has been a lot) will end up being just pissing in the wind.

Once again, it is at the PEP author's peril to not listen to people's
suggestions and risk the PEP not being accepted due to the design not
meeting standards for acceptance. And they are still required to keep the
Rejected Ideas section of the PEP up-to-date or else the PEP will not be
considered.

>   (I
> don't mean to be vulgar or disrespectful; I just can't think of another
> phrase that conveys my meaning so well.)

I think you're looking for "ignored".

-Brett

>   And Guido's 2nd email ("PEP
> 622: Structural Pattern Matching -- followup") already to me (YMMV)
> reads rather like "OK, you've had your fun, now try not to joggle our
> elbows too much while we get on with the work".
>
> I don't know how many of the decisions made in the PEP are right and how
> many could be improved (it is of course a subjective question anyway).
> I do think it's a pity that the Python community did not have the chance
> to supply feedback earlier down the road (when IMO it would have been
> taken more seriously).
> While Guido and the other developers have obviously already put a huge
> amount of work into this PEP (and by now probably have a significant
> emotional investment in it), I do hope that they will take the time to
> consider seriously and on their merits most/all suggested changes,
> rather than being tempted to rush through the acceptance and
> implementation of the PEP.
>
> Best wishes
> Rob Cliffe
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/IG4VNKZF4J7OR3L665PE26KL7L6SFQSQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/PWEGG4L4LV4GG3R5NLK7NV6NXBQJ2IQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 railroaded through?

2020-07-03 Thread Terry Reedy

On 7/1/2020 4:14 PM, Rob Cliffe via Python-Dev wrote:

I have an uneasy feeling about this PEP.

I can understand that.

The PEP is accepted (if it is).
(Then and only then) Someone works on the implementation.
etc.

To the extent that this is true, a big reason is that many people do not
want to write code until they are somewhat sure it will be accepted.
But we can almost never be sure until we know what the code is, or will
be -- in detail.

'Show us some code' is common in discussion. Is the feature possible,
or are we wasting out time discussing it? Will it be fast enough? Will
the code be maintainable? Or too ugly to look at?

The same issue comes up on bpo issues. 'Please either give a really
detailed specification, or submit a PR.' 'Will it be accepted?' 'We
cannot tell until we see it.'

Sometimes, someone not a PEP or bpo issue author offers to contribute an
implementation to move discussion along to possible acceptance.

However, PEP 622 only seems to have been presented to the Python
community only *after* a well-developed (if not finalised)
implementation was built. A fait accompli.

I would be annoyed too if I thought it were true, but I don't. AFAIK,
the implementation on someone's private fork has not yet been presented
as a PR ready to be committed at the press of the green button.

And since the PEP has Guido's authority behind it, I think
it is likely that it will eventually be accepted pretty much as it was
originally written.

I suspect that Guido retired from the decision council in part so that
he could submit PEP level changes to it as an independent person not on
the council.

The new PEG parser was the first new PEP. I believe Guido was looking at
PEG parsers last summer, before last fall's council election. The
theoretical advantage was clear; the practical application to Python not
so much. He refrained from submitting a PEP until he had a couple of
collaborators to help produce an initial implementation that answered
the inevitable questions that would have made discussion without an
implementation moot. Is a PEG parser matching the current parser
possible?, fast enough?, compact enough?, and 'will there be the needed
follow through maintenance'?

It is common for a reasonably complicated context free grammar to be
ambiguous in the sense that a given sequence of tokens can be produced
by more than one sequence of applications of the production rules. But
we want machine parsing of code to a particular sequence to be
unambiguious, deterministic, and fast. An LL(1) parser uses and is
limited to one token lookahead and cannot unambiguously parse all
context-free languages. The PEG parser cuts the ambiguity knot by
ordering production rules and accepting the first match.

This is the same rule proposed for match statements and is similar to
the disambiguating rule for if statements in Python and many other
languages (but not all): first true condition wins. (Python also does
the same for expressions with side-effects with a left-to-right
evaluation rule.) Each condition is implicitly augmented with 'and none
of the previous conditions'. In ordered matching, each pattern has a
similar implicit condition.

Ordered evaluation at the expression level is not much of an issue for
human readers. I think making words keywords only in certain easily
read contexts, such as 'match' followed by followed by ':',
is also not much of an issue.

I suspect that some of the proposed match patterns require the new PEP
parser and that this has something to do with people's uneasiness.
Removing the LL(1) limitation lets us add grammar rules that we want,
but also allows for constructions that are unneeded* or hard for humans
to read.

*Prior to the match proposal, Guido reported on python-ideas that he had
developed a PEG grammar and resulting parser and compiler that allowed
for omitting parentheses in at least some calls with arguments. He
dropped the idea when the coredev reaction was neutral to negative.

--
Terry Jan Reedy

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/WCGSM2BA7PMI6DN3Q6MJOLR4EKV5SCI5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.9.0b4 is now ready for testing

2020-07-03 Thread Łukasz Langa

On behalf of the entire Python development community, and the currently serving 
Python release team in particular, I’m pleased to announce the release of 
Python 3.9.0b4. Get it here:

https://www.python.org/downloads/release/python-390b4/ 


This is a beta preview of Python 3.9

Python 3.9 is still in development. This release, 3.9.0b4, is the fourth of 
five planned beta release previews.

Beta release previews are intended to give the wider community the opportunity 
to test new features and bug fixes and to prepare their projects to support the 
new feature release.

Call to action

We strongly encourage maintainers of third-party Python projects to test with 
3.9 during the beta phase and report issues found to the Python bug tracker 
 as soon as possible. While the release is planned to 
be feature complete entering the beta phase, it is possible that features may 
be modified or, in rare cases, deleted up until the start of the release 
candidate phase (2020-08-10). Our goal is have no ABI changes after beta 5 and 
as few code changes as possible after 3.9.0rc1, the first release candidate. To 
achieve that, it will be extremely important to get as much exposure for 3.9 as 
possible during the beta phase.

Please keep in mind that this is a preview release and its use is not 
recommended for production environments.

Major new features of the 3.9 series, compared to 3.8

Some of the new major new features and changes in Python 3.9 are:

PEP 584 , Union Operators in dict

PEP 585 , Type Hinting Generics In 
Standard Collections

PEP 593 , Flexible function and 
variable annotations

PEP 602 , Python adopts a stable 
annual release cadence

PEP 615 , Support for the IANA Time 
Zone Database in the Standard Library

PEP 616 , String methods to remove 
prefixes and suffixes

PEP 617 , New PEG parser for CPython

BPO 38379 , garbage collection does not 
block on resurrected objects;

BPO 38692 , os.pidfd_open added that allows 
process management without races and signals;

BPO 39926 , Unicode support updated to 
version 13.0.0;

BPO 1635741 , when Python is initialized 
multiple times in the same process, it does not leak memory anymore;

A number of Python builtins (range, tuple, set, frozenset, list, dict) are now 
sped up using PEP 590  vectorcall;

A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, 
_functools, _json, _locale, operator, resource, time, _weakref) now use 
multiphase initialization as defined by PEP 489 
;

A number of standard library modules (audioop, ast, grp, _hashlib, pwd, 
_posixsubprocess, random, select, struct, termios, zlib) are now using the 
stable ABI defined by PEP 384 .

(Hey, fellow core developer, if a feature you find important is missing from 
this list, let Łukasz know .)

The next pre-release, the fifth beta release of Python 3.9, will be 3.9.0b5. It 
is currently scheduled for 2020-07-20.

More resources

Online Documentation 
PEP 596 , 3.9 Release Schedule
Report bugs at https://bugs.python.org .
Help fund Python and its community .
Your friendly release team,
Ned Deily @nad 
Steve Dower @steve.dower 
Łukasz Langa @ambv ___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2YXZ35N5IIHC2VXQ3IIFJOX2B32ZJASP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Greg Ewing


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

Specifying British English


"British English" is woefully underspecified -- there are probably more
variants of English used in Britain than in the rest of the world put
together.

--
Greg
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/PJQ2HBYLELRGSZ2DPVZED6CJCPE2YR6Y/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-07-03 Thread Greg Ewing


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

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


Maybe we should use randomly generated names for hypothetical persons?

--
Greg
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/XAYDVYQVX7TQ467LQFMRA5M6CMU7SJBR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 railroaded through?

2020-07-03 Thread Brandt Bucher

Since I took it upon myself to implement PEP 622, I just have a few thoughts to 
add to the other excellent responses here. Hopefully these will help clarify 
that the intent is not to "railroad" anything.

Rob Cliffe wrote:
> PEP 622 only seems to have been presented to the Python community only after 
> a well-developed (if not finalised) implementation was built.

Well, thanks for the "well-developed" bit, but I promise that the 
implementation is far from final. Since we first published the PEP, I've made 
dozens of commits touching pretty much every new line of code several times. 
Just last week we gutted the __match__ method in response to well-reasoned 
calls to defer it.

> So there will inevitably be resistance from the developers to accept changes 
> suggested on python-dev.

As the one who has been doing almost all of the development, I assure you this 
isn't true. 80% of the PEP's authors have been almost entirely detached from 
development of the reference implementation, so I would be very surprised if 
they gave my existing work more weight than the opinions of the community... I 
wrote the thing, and I certainly don't!

I volunteered to implement it because I thought the PEP and implementation 
would be an interesting project while trapped at home this spring. I *like* 
doing this stuff, so I'm not really worried about getting to do more of it. ;)

> And since the PEP has Guido's authority behind it, I think it is likely that 
> it will eventually be accepted pretty much as it was originally written.

It has already changed quite substantially from how it was originally written. 
Here's everything that's changed since we posted the first draft (we've been 
pretty much dominating PEP repo traffic over the past week):

https://github.com/python/peps/commits/master/pep-0622.rst

Again, you'll notice that the entire __match__ protocol was deferred based on 
feedback we received, and we've made an effort to describe the reasoning behind 
many decisions that seemed obvious to us but weren't to others. The opening 
sections are also getting a rewrite (again, based on Python-Dev feedback).

> Guido's 2nd email ("PEP 622: Structural Pattern Matching -- followup") 
> already to me (YMMV) reads rather like "OK, you've had your fun, now try not 
> to joggle our elbows too much while we get on with the work".

That's an extremely odd way to interpret his thread, which exists solely to 
collect of all of the "unheard" critiques in one central location.

> I do think it's a pity that the Python community did not have the chance to 
> supply feedback earlier down the road (when IMO it would have been taken more 
> seriously).

It did. The very first thing we did was perform detailed surveys of 8 different 
Python-Ideas threads (spanning 9 years), 13 other languages, and a handful of 
the most popular Python packages for pattern matching. This is not at all the 
first time this has been brought up by the community; I personally worked my 
way through hundreds of emails and dozens of documents before writing a single 
line of code (or PEP).

> While Guido and the other developers have obviously already put a huge amount 
> of work into this PEP (and by now probably have a significant emotional 
> investment in it), I do hope that they will take the time to consider 
> seriously and on their merits most/all suggested changes, rather than being 
> tempted to rush through the acceptance and implementation of the PEP.

Don't worry; I have a much stronger emotional connection to Python's continued 
success and community than to a quarantine project that Guido nerd-sniped me 
with a few months ago. ;)

Brandt
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JB7WSMUUVBNDYSNLECJEYK75WFSJMM6X/
Code of Conduct: http://python.org/psf/codeofconduct/

40 matches

Mail list logo