[Python-Dev] Re: Comments on PEP 558

2021-02-04 Thread Sven R. Kunze 

On 03.02.21 23:37, Nick Coghlan wrote:


No, PEP 558 doesn't remove it, it enhances it to be a live view of the 
frame state instead of an inconsistently updated snapshot.



As long as it is possible to **write** to existing keys to **add new 
keys** to frame.f_locals, I am actually quite happy.



The potential incompatibility Mark is referring to is the fact that 
even optimised frames currently allow writing to arbitrary keys in 
frame.f_locals and making the bound values visible to the locals() 
builtin and other consumers of frame.f_locals.


For PEP 558, it's an open question as to whether that behaviour will 
become limited to the PyEval_GetLocals() backwards compatible C API, 
with the updated Python frame API instead throwing KeyError for 
attempts to write to unknown keys on optimised frames.


So, it seems the restricting behavior is for special cases only (not 
including with-statements which I would care about).



I just wanted to mention that accessing problematic parts of the 
interpreter's internals can be quite helpful when doing concept-proofing 
or working the way through until a "batteries-included" solution exist.


Thanks,
Sven

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

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

2021-02-04 Thread Stefano Borini 
On Thu, 4 Feb 2021 at 01:21, Petr Viktorin  wrote:

> The PEP does lack a "How to teach" section.

I can add it tonight, and I think it would clarify some corner cases
to make them more natural.
Do you have something specific you are concerned about, when it comes
to "teachability" (stress point, hard to grok, expected common
mistakes)?

I'd focus only on the use of the feature "from the outside", that is,
using the indexing operation as a common user.
For implementing the dunders, it's an advanced feature and it's
unlikely to be discussed during basic teaching sessions.



-- 
Kind regards,

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

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

2021-02-04 Thread Paul Moore 
On Thu, 4 Feb 2021 at 10:34, Stefano Borini  wrote:
> I'd focus only on the use of the feature "from the outside", that is,
> using the indexing operation as a common user.
> For implementing the dunders, it's an advanced feature and it's
> unlikely to be discussed during basic teaching sessions.

I think there's value in having a note about how to promote "best
practices" in implementing the dunders under "How to teach". A
relevant point about the proposal is whether it's too easy for people
to fall into traps when implementing the functionality, and this is a
good section to discuss that. It should be covered by noting where in
the documentation it'll be discussed, so I don't think it's a big
deal, but it's worth having.

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

[Python-Dev] Re: Comments on PEP 558

2021-02-04 Thread Mark Shannon 

Hi Sven,

On 04/02/2021 9:06 am, Sven R. Kunze wrote:

On 03.02.21 23:37, Nick Coghlan wrote:


No, PEP 558 doesn't remove it, it enhances it to be a live view of the 
frame state instead of an inconsistently updated snapshot.



As long as it is possible to **write** to existing keys to **add new 
keys** to frame.f_locals, I am actually quite happy.


Out of interest, why would you want to add new keys to the locals of a 
function frame?

The function will never be able to use those values.




The potential incompatibility Mark is referring to is the fact that 
even optimised frames currently allow writing to arbitrary keys in 
frame.f_locals and making the bound values visible to the locals() 
builtin and other consumers of frame.f_locals.


For PEP 558, it's an open question as to whether that behaviour will 
become limited to the PyEval_GetLocals() backwards compatible C API, 
with the updated Python frame API instead throwing KeyError for 
attempts to write to unknown keys on optimised frames.


So, it seems the restricting behavior is for special cases only (not 
including with-statements which I would care about).



I just wanted to mention that accessing problematic parts of the 
interpreter's internals can be quite helpful when doing concept-proofing 
or working the way through until a "batteries-included" solution exist.


Thanks,
Sven



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

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

2021-02-04 Thread Walter Dörwald 

On 2 Feb 2021, at 12:36, Stefano Borini wrote:


Hi all,

I would like to request feedback by python-dev on the current
implementation of PEP 637 - Support for indexing with keyword
arguments.

https://www.python.org/dev/peps/pep-0637/

The PEP is ready for SC submission and it has a prototype
implementation ready, available here (note, not reviewed, but
apparently fully functional)

https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2

(note: not sure if there's a preference for the link to be to the diff
or to the branch, let me know if you prefer I change the PEP link)


It seems to me, that what complicates the specification is the need for 
backwards compatibility. If that wasn't an issue, we could make indexing 
operations behave exactly like function calls. Handling the additional 
argument for `__setitem__` could be done the same way that passing 
`self` in a method call is done: By passing an additional positional 
argument (in this case as the second argument after `self`), So:


*   `foo[1]` is `type(foo).__getitem__(foo, 1)`
*   `foo[1, 2]` is `type(foo).__getitem__(foo, 1, 2)`
*   `foo[(1, 2)]` is `type(foo).__getitem__(foo, (1, 2))`
*   `foo[1] = 3` is `type(foo).__setitem__(foo, 3, 1)`
*   `foo[1, 2] = 3` is `type(foo).__setitem__(foo, 3, 1, 2)`
*   `foo[(1, 2)] = 3` is `type(foo).__setitem__(foo, 3, (1, 2))`

But of course this isn't backwards compatible with respect to the 
treatment of tuple arguments and the argument order in `__setitem__`. 
However it is **much** easier to remember and to teach.


The PEP rejects the idea to implement this approach via a new set of 
dunder methods (e.g. `__getitem_ex__`, `__setitem_ex__` and 
`__delitem_ex__`) for performance reasons, but would it make sense, to 
mark existing `__getitem__`, `__setitem__` and `__delitem__` methods as 
supporting the new calling convention via a decorator? i.e something 
like:



```python
class X:
@newstyle_item
def __getitem__(self, x, y, z=42):
...

@newstyle_item
def __setitem__(self, value, x, y, z=42):
...

@newstyle_item
def __detitem__(self, x, y, z=42):
...
```

This wouldn't require an additional dictionary lookup, but just a check 
of a bit in the function object.



Thank you for your help.


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

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

2021-02-04 Thread Inada Naoki 
On Tue, Feb 2, 2021 at 8:40 PM Inada Naoki  wrote:
>
> On Tue, Feb 2, 2021 at 7:37 PM M.-A. Lemburg  wrote:
> >
> > BTW: I don't understand this comment:
> > "They are inefficient on platforms wchar_t* is UTF-16. It is because
> > built-in codecs supports only UCS-1, UCS-2, and UCS-4 input."
> >
> > Windows is one such platform. Java (indirectly) is another. They both
> > store UTF-16LE in those arrays and Python's codecs handle this just
> > fine.
> >
>
> I'm sorry about the section is not clear.
>
> For example, if wchar_t* is UCS4, ucs4_utf8_encoder() can encode
> wchar_t* into UTF-8.
>
> But when wchar_t* is UTF-16, ucs2_utf8_encoder() can not handle
> surrogate escape.
> We need to use a temporary Unicode object. That is what "inefficient" means.
>
> I will update the section more elaborate.
>

I updated the "Alternative Ideas" section of the PEP.
https://www.python.org/dev/peps/pep-0624/#alternative-ideas

They replaces `Py_UNICODE*` with `PyObject*`, `Py_UCS4*`, and `wchar_t*`.
I explicitly noted that some codecs can bypass temporary Unicode objects:

"""
UTF-8, UTF-16, UTF-32 encoders support Py_UCS4 internally. So
PyUnicode_EncodeUTF8(), PyUnicode_EncodeUTF16(), and
PyUnicode_EncodeUTF32() can avoid to create a temporary Unicode
object.
"""

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

[Python-Dev] Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

2021-02-04 Thread Guido van Rossum 
Hi Larry,

Can you give us a status update for your PEP 649? I don't recall reading
anything about it in the past few weeks. I am super excited about this
solution to the problem (even if there are a few issues to work through)
and I think it will provide better backwards compatibility than the current
plan for Python 3.10 (PEP 563, from __future__ import annotations, causing
all annotations to be stringified).

If we don't get this into 3.10, we'd have a much more complicated
transition. There are only two more alphas before 3.10b1 gets released! And
we'd have to get this approved by the Steering Council, which can take a
few weeks (cut them some slack, they have a big backlog). Fortunately you
already have an implementation that can be landed quickly once the PEP is
accepted.

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

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

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

2021-02-04 Thread Larry Hastings 


After working on it and stressing out about it for some months, I 
decided to take a break and scratch some other itches.  I'll return to 
PEP 649 soon, and I have every intention of having the PEP done and the 
prototype done well in advance of 3.10b1--worry not.


Thanks for checking in,


//arry/

On 2/4/21 9:17 AM, Guido van Rossum wrote:

Hi Larry,

Can you give us a status update for your PEP 649? I don't recall 
reading anything about it in the past few weeks. I am super excited 
about this solution to the problem (even if there are a few issues to 
work through) and I think it will provide better backwards 
compatibility than the current plan for Python 3.10 (PEP 563, from 
__future__ import annotations, causing all annotations to be stringified).


If we don't get this into 3.10, we'd have a much more complicated 
transition. There are only two more alphas before 3.10b1 gets 
released! And we'd have to get this approved by the Steering Council, 
which can take a few weeks (cut them some slack, they have a big 
backlog). Fortunately you already have an implementation that can be 
landed quickly once the PEP is accepted.


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

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

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

2021-02-04 Thread Guido van Rossum 
Breaks are good. Looking forward to the next prototype!

On Thu, Feb 4, 2021 at 10:45 AM Larry Hastings  wrote:

>
> After working on it and stressing out about it for some months, I decided
> to take a break and scratch some other itches.  I'll return to PEP 649
> soon, and I have every intention of having the PEP done and the prototype
> done well in advance of 3.10b1--worry not.
>
> Thanks for checking in,
>
>
> */arry*
> On 2/4/21 9:17 AM, Guido van Rossum wrote:
>
> Hi Larry,
>
> Can you give us a status update for your PEP 649? I don't recall reading
> anything about it in the past few weeks. I am super excited about this
> solution to the problem (even if there are a few issues to work through)
> and I think it will provide better backwards compatibility than the current
> plan for Python 3.10 (PEP 563, from __future__ import annotations, causing
> all annotations to be stringified).
>
> If we don't get this into 3.10, we'd have a much more complicated
> transition. There are only two more alphas before 3.10b1 gets released! And
> we'd have to get this approved by the Steering Council, which can take a
> few weeks (cut them some slack, they have a big backlog). Fortunately you
> already have an implementation that can be landed quickly once the PEP is
> accepted.
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
>
>

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

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

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

2021-02-04 Thread Guido van Rossum 
We have examined every possible permutation already, I think this would be
a distraction to pursue.

On Thu, Feb 4, 2021 at 04:20 Walter Dörwald  wrote:

> On 2 Feb 2021, at 12:36, Stefano Borini wrote:
>
> Hi all,
>
> I would like to request feedback by python-dev on the current
> implementation of PEP 637 - Support for indexing with keyword
> arguments.
>
> https://www.python.org/dev/peps/pep-0637/
>
> The PEP is ready for SC submission and it has a prototype
> implementation ready, available here (note, not reviewed, but
> apparently fully functional)
>
>
> https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2
>
> (note: not sure if there's a preference for the link to be to the diff
> or to the branch, let me know if you prefer I change the PEP link)
>
> It seems to me, that what complicates the specification is the need for
> backwards compatibility. If that wasn't an issue, we could make indexing
> operations behave exactly like function calls. Handling the additional
> argument for __setitem__ could be done the same way that passing self in
> a method call is done: By passing an additional positional argument (in
> this case as the second argument after self), So:
>
>- foo[1] is type(foo).__getitem__(foo, 1)
>- foo[1, 2] is type(foo).__getitem__(foo, 1, 2)
>- foo[(1, 2)] is type(foo).__getitem__(foo, (1, 2))
>- foo[1] = 3 is type(foo).__setitem__(foo, 3, 1)
>- foo[1, 2] = 3 is type(foo).__setitem__(foo, 3, 1, 2)
>- foo[(1, 2)] = 3 is type(foo).__setitem__(foo, 3, (1, 2))
>
> But of course this isn't backwards compatible with respect to the
> treatment of tuple arguments and the argument order in __setitem__.
> However it is *much* easier to remember and to teach.
>
> The PEP rejects the idea to implement this approach via a new set of
> dunder methods (e.g. __getitem_ex__, __setitem_ex__ and __delitem_ex__)
> for performance reasons, but would it make sense, to mark existing
> __getitem__, __setitem__ and __delitem__ methods as supporting the new
> calling convention via a decorator? i.e something like:
>
> class X:
> @newstyle_item
> def __getitem__(self, x, y, z=42):
> ...
>
> @newstyle_item
> def __setitem__(self, value, x, y, z=42):
> ...
>
> @newstyle_item
> def __detitem__(self, x, y, z=42):
> ...
>
> This wouldn't require an additional dictionary lookup, but just a check of
> a bit in the function object.
>
> Thank you for your help.
>
> 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/DTOO36EXJRBGA7OJVTRAE7I43D2FR7BS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/EACMAG7WM25KPSNHSEGW5M4K2WL2B6MV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] What's up with assignment expression and tuples?

2021-02-04 Thread Paul Sokolovsky 
Hello,

Everyone knows how hard to find a compelling usecase for the assignment
expression operator (":=", colloquially "walrus operator").
https://www.python.org/dev/peps/pep-0572/ examples never felt
compelling and we all remember the split it caused.

I finally found a usecase where *not* using assignment expression is
*much* worse than using it. I'm working on SSA (Static Single
Assignment,
https://en.wikipedia.org/wiki/Static_single_assignment_form) conversion
of Python programs, where there's a need to "join" dataflow of values
from different control flow paths using a special function (Phi
function). This "joining" itself creates a new variable, and of course,
the original variable was used in an expression. We've got
assignment in expression, assignment expression operator to the rescue!

With it, a simple loop like:


a = 0
while a < 5:
a += 1


becomes:


a0 = 0
while (a1 := phi(a0, a2)) < 5:
a2 = a1 + 1


So far, so good. But semantics of Phi function is parallel assignment.
No problem with Python either, "a, b = b, c" is exactly parallel
assignment. So, let's try example with 2 variables:


a = 0
b = 10
while a < 5:
a += 1
b += 1


becomes:


a0 = 0
b0 = 10
while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
a2 = a1 + 1
b2 = b1 + 1


But oops:

> SyntaxError: cannot use assignment expressions with tuple

To reproduce in the REPL:


>>> ((a, b) := (1, 2))
  File "", line 1
SyntaxError: cannot use assignment expressions with tuple


Why this accidental syntactic gap? Why assignment statement can do
parallel assignment with a tuple on LHS, and assignment operator
suddenly can't?

Why the adhoc naming and conceptual shift on the AST level, when PEP572
explicitly talks about *assignment operator*, but corresponding node on
the AST level is called NamedExpr? Why look at assignment expression as
"name of expression" instead of assignment expression per se?

It's of course not a problem to recast:

NamedExpr(expr target, expr value)

to

NamedExpr(expr* target, expr value)

in the ASDL (and it works out of the box), the point is that it should
have been ExprAssign from the start (folloing the AugAssign and
AnnAssign tradition).


-- 
Best regards,
 Paul  mailto:[email protected]
___
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/6IFDG7PAFPHVPGULANOQDAHP2X743HCE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-04 Thread Inada Naoki 
On Tue, Feb 2, 2021 at 8:16 PM Victor Stinner  wrote:
>
> > > I understand that encoding=locale.get_locale_encoding() would be
> > > different from encoding="locale":
> > > encoding=locale.get_locale_encoding() doesn't call
> > > os.device_encoding(), right?
> > >
> >
> > Yes.
>
> Would it be useful to add a io.get_locale_encoding(fd)->str (maybe
> "get_default_encoding"?) function which gives the chosen encoding from
> a file descriptor, similar to open(fd, encoding="locale").encoding?
> The os.device_encoding() call is not obvious.
>

I don't think it's so useful. encoding=None is 99% same to
encoding=locale.getpreferedencoding(False).

On Unix, os.device_encoding() just returns locale encoding.
On Windows, os.device_encoding() is very unlikely used. open() uses
WindowsConsoleIO for console unless PYTHONLEGACYWINDOWSSTDIO is set
and encoding for it is UTF-8.

And that's why I removed the detailed behavior from the PEP. It is too
detailed and almost unrelated to EncodingWarning.
I wrote a simple comment in this section instead.
https://www.python.org/dev/peps/pep-0597/#locale-is-not-a-codec-alias

>
> > > > Opt-in warning
> > > > ---
> > > >
> > > > Although ``DeprecationWarning`` is suppressed by default, emitting
> > > > ``DeprecationWarning`` always when ``encoding`` option is omitted
> > > > would be too noisy.
> > >
> > > The PEP is not very clear. Does "-X warn_encoding" only emits the
> > > warning, or does it also display it by default? Does it add a warning
> > > filter for EncodingWarning?
> > >
> >
> > This section is not the spec. This section is the rationale for adding
> > EncodingWarning instead of using DeprecationWarning.
> >
> > As spec saying, EncodingWarning is a subclass of Warning. So it is
> > displayed by default. But it is not emitted by default.
> >
> > When -X encoding_warning (or -X warn_default_encoding) is used, the
> > warning is emitted and shown unless the user suppresses warnings.
>
> I understand that EncodingWarning is always displayed by default
> (default warning filters don't ignore it, whereas DeprecationWarning
> are ignored by default), but no warning is emitted by default. Ok,
> that makes sense. Maybe try to say it explicitly in the PEP.
>
>
> > This PEP doesn't have "backward compatibility" section because the PEP
> > doesn't break any backward compatibility.
>
> IMO it's a good thing to always have the section, just to say that you
> took time to think about backward compatibility ;-) The section can be
> empty, like just say "there is no incompatible change" ;-)
>
>
> > And if developers want to support Python ~3.9 and use -X
> > warn_default_encoding on 3.10, they need to write
> > `encoding=getattr(io, "LOCALE_ENCODING", None)`, as written in the
> > spec.
>
> Maybe repeat it in the Backward Compatibility section.
>
> It's important to provide a way to prevent the warning without losing
> the support for old Python versions.
>

will do.

>
> > > The main question is if it's possible to use encoding="locale" on
> > > Python 3.6-3.9 (maybe using some ugly hacks).
> >
> > No.
>
> Hum. To write code compatible with Python 3.9, I understand that
> encoding=None is the closest to encoding="locale".
>
> And I understand that encoding=getattr(io, "LOCALE_ENCODING", None) is
> backward and forward compatible ;-)
>
> Well, encoding=None will hopefully remain accepted with your PEP
> anyway for lazy developers ;-)
>

Yes. I don't think this warning is enabled by default in near future.
So developers can just use the option to find missing `encoding="utf-8"` bug.


>
> > Oh, I'm sorry. I want to make it in 3.10.
>
> Since it doesn't change anything by default, the warning is only
> displayed when you opt-in for it, IMO Python 3.10 target is
> reasonable.
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.

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