[Python-ideas] Re: argparse: mutually inclusive arguments

[Stephen J. Turnbull]

Oscar Benjamin writes:
 > On Fri, 26 Feb 2021 at 02:49, Stephen J. Turnbull
 >  wrote:

 > > Thing is, this "mutual inclusion" condition isn't really about parsing
 > > (ie, syntax)[1]; this is about semantics -- like all input validation.
 > > I don't object to having it in argparse, but it's going to be so
 > > domain-dependent that I don't think we should do more than provide
 > > hooks to validate individual arguments (eg, a 0 <= p <= 1 constraint
 > > on probabilities or proportions), and an args.validate hook to do
 > > cross-argument validation.
 > 
 > Given that the hook would just be called after parsing the args would
 > be the advantage of using a hook compared to just validating the args
 > yourself after calling parse_args?

"Quis custodiat ipsos custodes?"  That is, it has no extra value in
validating the args, but by providing a standard place to put
validation code, it helps us to validate the validators.  For most of
my scripts, I'm not going to write *any* command line validation code,
but for programs called by other tools, I think it would be helpful to
me to have all command line validation in one standard place.

We could even have a tool in argparse to report which arguments have
validators and which don't, though that smells like overkill (and I
myself would probably write it as a search in Emacs Lisp rather than
use an argparse-provided tool).

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/A22OJJSJOZ33ITLOBXLASK37LU3IB67Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Barrier Object in asyncio lib

[Paul Bryan]

Sorry, didn't see Jonathan's example.

On Sat, 2021-02-27 at 01:12 +, Paul Bryan wrote:
> Could somone provide a concrete example on a proposed use of such an
> asyncio.Barrier?
> 
> On Fri, 2021-02-26 at 14:19 -0800, Guido van Rossum wrote:
> > On Fri, Feb 26, 2021 at 10:09 AM Yves Duprat 
> > wrote:
> > > I was expecting an explanation about the initial request. 
> > > Is there an oversight (??) or an another reason to not have a
> > > Barrier primitive in asyncio ?
> > > 
> > 
> > 
> > Probably because nobody working on asyncio at the time had any
> > experience using threading.Barrier. I know that I have used all the
> > other primitives, but I don't recall ever having used Barrier. I
> > don't think there's anything deeper than that. You should probably
> > just open a bpo issue (mention this thread) and submit a PR linked
> > there. I can't promise to review it though. :-)
> >  
> > ___
> > Python-ideas mailing list -- python-ideas@python.org
> > To unsubscribe send an email to python-ideas-le...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> > https://mail.python.org/archives/list/python-ideas@python.org/message/GNUCKA2MCVROCVLWRQUTMUG7CGOVQQV6/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/WIQBCDBZSJQDDBDQQSOYLU4C2XIBGDKN/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/F2GKBLMU5JBYNUGDPBGNGTRZGBCH3M2R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Barrier Object in asyncio lib

[Paul Bryan]

Could somone provide a concrete example on a proposed use of such an
asyncio.Barrier?

On Fri, 2021-02-26 at 14:19 -0800, Guido van Rossum wrote:
> On Fri, Feb 26, 2021 at 10:09 AM Yves Duprat 
> wrote:
> > I was expecting an explanation about the initial request. 
> > Is there an oversight (??) or an another reason to not have a
> > Barrier primitive in asyncio ?
> > 
> 
> 
> Probably because nobody working on asyncio at the time had any
> experience using threading.Barrier. I know that I have used all the
> other primitives, but I don't recall ever having used Barrier. I
> don't think there's anything deeper than that. You should probably
> just open a bpo issue (mention this thread) and submit a PR linked
> there. I can't promise to review it though. :-)
>  
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/GNUCKA2MCVROCVLWRQUTMUG7CGOVQQV6/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WIQBCDBZSJQDDBDQQSOYLU4C2XIBGDKN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Barrier Object in asyncio lib

[Guido van Rossum]

On Fri, Feb 26, 2021 at 10:09 AM Yves Duprat  wrote:

> I was expecting an explanation about the initial request.
> Is there an oversight (??) or an another reason to not have a Barrier
> primitive in asyncio ?
>

Probably because nobody working on asyncio at the time had any experience
using threading.Barrier. I know that I have used all the other primitives,
but I don't recall ever having used Barrier. I don't think there's anything
deeper than that. You should probably just open a bpo issue (mention this
thread) and submit a PR linked there. I can't promise to review it though.
:-)

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

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GNUCKA2MCVROCVLWRQUTMUG7CGOVQQV6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Barrier Object in asyncio lib

[Yves Duprat]

  
  
I was expecting an explanation about the initial request. 
Is there an oversight (??) or an another reason to not have a
Barrier primitive in asyncio ?

@jonathan: as proposed, I will fill an issue on bugs.python.org.
Thank you Jonathan and Barry for the discussion

Yves


Le 26/02/2021 à 11:27, Jonathan
  Slenders a écrit :


  
  


>> Why would you need locks for async? Is
  it to sync with things outside of the async process?


`asyncio.Lock` is needed to lock across async operations.
  (If there is an `await` in the body for the lock).




  Le ven. 26 févr. 2021
à 10:45, Barry Scott  a
écrit :
  
  

  

  On 26 Feb 2021, at 08:31, Jonathan Slenders 
wrote:
  
  

  Barry,
  
  
  What you describe sounds like
`asyncio.gather(...)` if I understand correctly.
  
  
  The thing with a Barier is that it's usable
in situations where we don't know the other
tasks. Maybe there is no reference to them from
the current scope. Maybe they are even not yet
created.
  It certainly can be done with a list of
`asyncio.Future` and `asyncio.gather(...)`, but
that's a lot of boilerplate.
  
  
  IMHO, Yves is right. For both asyncio and
threading, we have Lock, Event, Condition,
Semaphore and BoundedSemaphore. Only Barier is
missing among the asyncio primitives. (RLock
doesn't make sense.)

  



Why would you need locks for async? Is it to sync
  with things outside of the async process?


With the large and complex async app I work on
  there are no locks at all.


  

  (I guess we can probably go to bugs.python.org
with this proposal.)

  



Having shown that a Barrier for async is a missing
  piece it would be good to get a thumbs up here.


Barry



  

  
  
  Jonathan
  
  
  
  
  
  
  
  
  
  
  



  Le jeu. 25 févr.
2021 à 23:38, Barry Scott 
a écrit :
  
  

  

  On 25 Feb 2021, at 17:15, Jonathan
Slenders 
wrote:
  
  

  It does make sense to have a
barrier synchronization primitive
for asyncio.
  The idea is to make a coroutine
block until at least X coroutines
are waiting to enter the barrier.
  This is very useful, if certain
actions need to be synchronized.

  



I do most of my async coding with
  twisted where what you calling a barrier
  is a DeferredList.


The way its used is that you add 

[Python-ideas] Re: argparse: mutually inclusive arguments

[Oscar Benjamin]

On Fri, 26 Feb 2021 at 02:49, Stephen J. Turnbull
 wrote:
>
> David Mertz writes:
>  > On Wed, Feb 24, 2021 at 1:38 PM Paul Korir  wrote:
>  >
>  > > I've been using the argparse library for a long time and one use case 
> that
>  > > repeatedly shows us is the need to have two arguments appear together i.e
>  > > either both appear or none of them appear. I'll refer to these as 
> *mutually
>  > > inclusive* in contrast to the existing *mutual exclusive* feature 
> present.
>  > > I might be wrong but there seems to be no way to enforce this.
>  > >
>  >
>  > I'm of mixed feelings about this.  I can absolutely see that it can be
>  > useful, and many tools will have this kind of argument requirement.
>
> Perhaps we could provide a more general facility for validation of the
> parsed argument values.  Of course this would be less convenient for
> the specific case of arguments that must be specified together with no
> other requirements, but I wonder how often that case arises.  In many
> cases there are other conditions, for example in specifying an
> interval, args.lower < args.upper (or <= if you'll accept a degenerate
> interval).
>
> Thing is, this "mutual inclusion" condition isn't really about parsing
> (ie, syntax)[1]; this is about semantics -- like all input validation.
> I don't object to having it in argparse, but it's going to be so
> domain-dependent that I don't think we should do more than provide
> hooks to validate individual arguments (eg, a 0 <= p <= 1 constraint
> on probabilities or proportions), and an args.validate hook to do
> cross-argument validation.

Given that the hook would just be called after parsing the args would
be the advantage of using a hook compared to just validating the args
yourself after calling parse_args?


Oscar
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UGZKHENX5XG24BV6HAP2H43SRUUSOXCC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Barrier Object in asyncio lib

[Jonathan Slenders]

>> Why would you need locks for async? Is it to sync with things outside of
the async process?

`asyncio.Lock` is needed to lock across async operations. (If there is an
`await` in the body for the lock).


Le ven. 26 févr. 2021 à 10:45, Barry Scott  a
écrit :

>
>
> On 26 Feb 2021, at 08:31, Jonathan Slenders  wrote:
>
> Barry,
>
> What you describe sounds like `asyncio.gather(...)` if I understand
> correctly.
>
> The thing with a Barier is that it's usable in situations where we don't
> know the other tasks. Maybe there is no reference to them from the current
> scope. Maybe they are even not yet created.
> It certainly can be done with a list of `asyncio.Future` and
> `asyncio.gather(...)`, but that's a lot of boilerplate.
>
> IMHO, Yves is right. For both asyncio and threading, we have Lock, Event,
> Condition, Semaphore and BoundedSemaphore. Only Barier is missing among the
> asyncio primitives. (RLock doesn't make sense.)
>
>
> Why would you need locks for async? Is it to sync with things outside of
> the async process?
>
> With the large and complex async app I work on there are no locks at all.
>
> (I guess we can probably go to bugs.python.org with this proposal.)
>
>
> Having shown that a Barrier for async is a missing piece it would be good
> to get a thumbs up here.
>
> Barry
>
>
> Jonathan
>
>
>
>
>
>
> Le jeu. 25 févr. 2021 à 23:38, Barry Scott  a
> écrit :
>
>>
>>
>> On 25 Feb 2021, at 17:15, Jonathan Slenders  wrote:
>>
>> It does make sense to have a barrier synchronization primitive for
>> asyncio.
>> The idea is to make a coroutine block until at least X coroutines are
>> waiting to enter the barrier.
>> This is very useful, if certain actions need to be synchronized.
>>
>>
>> I do most of my async coding with twisted where what you calling a
>> barrier is a DeferredList.
>>
>> The way its used is that you add in all the deferreds that you want to
>> complete before you continue
>> into the list. Once all the deferered have competed the DefferedList
>> completes and its callback is run.
>>
>> Barry
>>
>>
>>
>> Recently, I had to implement a barier myself for our use case. See code
>> below:
>>
>> It is simple to implement, but I too would like to have one for asyncio,
>> in order to be consistent with the concurrency primitives we have for
>> threading.
>>
>> Jonathan
>>
>>
>> class Barier:
>> """
>> Make a coroutine block until there are at least X waiters.
>>
>> Similar to the threading Barier objects but for asyncio:
>> https://docs.python.org/3/library/threading.html#barrier-objects
>> """
>>
>> def __init__(self, parties: int) -> None:
>> self.parties = parties
>> self._waiting: int
>> self._event = asyncio.Event()
>>
>> def add_one(self) -> None:
>> self._waiting += 1
>> if self._waiting == self.parties:
>> self._event.set()
>>
>> async def wait(self, worker: "Worker") -> None:
>> """
>> Wait until all we have at least `parties` waiters.
>> """
>> self.add_one()
>> await self._event.wait()
>>
>>
>>
>>
>> Le jeu. 25 févr. 2021 à 16:42, Barry Scott  a
>> écrit :
>>
>>>
>>>
>>> > On 25 Feb 2021, at 13:14, Yves Duprat  wrote:
>>> >
>>> > Hi,the list,
>>> >
>>> > I'm wondering why Barrier object does not exist in the synchronization
>>> primitives of the asyncio lib while it is present in threading and
>>> multiprocessing libs ?
>>> > This may not be the right place to ask this question, but I never
>>> found an answer on the web.
>>> > Thanks for your help.
>>>
>>>
>>> I'm assuming that the barrier you are speaking of is the mechanism that
>>> is used to
>>> synchronise threads/processes running in parallel to prevent data races.
>>>
>>> With async code that is never an issue. Each function runs to completion
>>> uninterrupted.
>>> There are no data races. Each time a async function runs it can know
>>> that the state of
>>> the objects it uses will not be changed while it is running.
>>>
>>> Barry
>>>
>>>
>>>
>>> >
>>> > Yves
>>> > ___
>>> > Python-ideas mailing list -- python-ideas@python.org
>>> > To unsubscribe send an email to python-ideas-le...@python.org
>>> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>> > Message archived at
>>> https://mail.python.org/archives/list/python-ideas@python.org/message/IAFAH7PWMUDUTLXYLNSXES7VMDQ26A3W/
>>> > Code of Conduct: http://python.org/psf/codeofconduct/
>>> >
>>> ___
>>> Python-ideas mailing list -- python-ideas@python.org
>>> To unsubscribe send an email to python-ideas-le...@python.org
>>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>> Message archived at
>>> https://mail.python.org/archives/list/python-ideas@python.org/message/B6WDPXNZH5KYK2BLHJXUFZF2DLFBLCBR/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>
___

[Python-ideas] Re: Barrier Object in asyncio lib

[Barry Scott]

> On 26 Feb 2021, at 08:31, Jonathan Slenders  wrote:
> 
> Barry,
> 
> What you describe sounds like `asyncio.gather(...)` if I understand correctly.
> 
> The thing with a Barier is that it's usable in situations where we don't know 
> the other tasks. Maybe there is no reference to them from the current scope. 
> Maybe they are even not yet created.
> It certainly can be done with a list of `asyncio.Future` and 
> `asyncio.gather(...)`, but that's a lot of boilerplate.
> 
> IMHO, Yves is right. For both asyncio and threading, we have Lock, Event, 
> Condition, Semaphore and BoundedSemaphore. Only Barier is missing among the 
> asyncio primitives. (RLock doesn't make sense.)

Why would you need locks for async? Is it to sync with things outside of the 
async process?

With the large and complex async app I work on there are no locks at all.

> (I guess we can probably go to bugs.python.org  with 
> this proposal.)

Having shown that a Barrier for async is a missing piece it would be good to 
get a thumbs up here.

Barry

> 
> Jonathan
> 
> 
> 
> 
> 
> 
> Le jeu. 25 févr. 2021 à 23:38, Barry Scott  > a écrit :
> 
> 
>> On 25 Feb 2021, at 17:15, Jonathan Slenders > > wrote:
>> 
>> It does make sense to have a barrier synchronization primitive for asyncio.
>> The idea is to make a coroutine block until at least X coroutines are 
>> waiting to enter the barrier.
>> This is very useful, if certain actions need to be synchronized.
> 
> I do most of my async coding with twisted where what you calling a barrier is 
> a DeferredList.
> 
> The way its used is that you add in all the deferreds that you want to 
> complete before you continue
> into the list. Once all the deferered have competed the DefferedList 
> completes and its callback is run.
> 
> Barry
> 
> 
>> 
>> Recently, I had to implement a barier myself for our use case. See code 
>> below:
>> 
>> It is simple to implement, but I too would like to have one for asyncio, in 
>> order to be consistent with the concurrency primitives we have for threading.
>> 
>> Jonathan
>> 
>> 
>> class Barier:
>> """
>> Make a coroutine block until there are at least X waiters.
>> 
>> Similar to the threading Barier objects but for asyncio:
>> https://docs.python.org/3/library/threading.html#barrier-objects 
>> 
>> """
>> 
>> def __init__(self, parties: int) -> None:
>> self.parties = parties
>> self._waiting: int
>> self._event = asyncio.Event()
>> 
>> def add_one(self) -> None:
>> self._waiting += 1
>> if self._waiting == self.parties:
>> self._event.set()
>> 
>> async def wait(self, worker: "Worker") -> None:
>> """
>> Wait until all we have at least `parties` waiters.
>> """
>> self.add_one()
>> await self._event.wait()
>> 
>> 
>> 
>> 
>> Le jeu. 25 févr. 2021 à 16:42, Barry Scott > > a écrit :
>> 
>> 
>> > On 25 Feb 2021, at 13:14, Yves Duprat > > > wrote:
>> > 
>> > Hi,the list,
>> > 
>> > I'm wondering why Barrier object does not exist in the synchronization 
>> > primitives of the asyncio lib while it is present in threading and 
>> > multiprocessing libs ?
>> > This may not be the right place to ask this question, but I never found an 
>> > answer on the web.
>> > Thanks for your help.
>> 
>> 
>> I'm assuming that the barrier you are speaking of is the mechanism that is 
>> used to
>> synchronise threads/processes running in parallel to prevent data races.
>> 
>> With async code that is never an issue. Each function runs to completion 
>> uninterrupted.
>> There are no data races. Each time a async function runs it can know that 
>> the state of
>> the objects it uses will not be changed while it is running.
>> 
>> Barry
>> 
>> 
>> 
>> > 
>> > Yves
>> > ___
>> > Python-ideas mailing list -- python-ideas@python.org 
>> > 
>> > To unsubscribe send an email to python-ideas-le...@python.org 
>> > 
>> > https://mail.python.org/mailman3/lists/python-ideas.python.org/ 
>> > 
>> > Message archived at 
>> > https://mail.python.org/archives/list/python-ideas@python.org/message/IAFAH7PWMUDUTLXYLNSXES7VMDQ26A3W/
>> >  
>> > 
>> > Code of Conduct: http://python.org/psf/codeofconduct/ 
>> > 
>> > 
>> ___
>> Python-ideas mailing list -- python-ideas@python.org 
>> 
>> To unsubscribe send an email to python-ideas-le...@python.org 
>> 

[Python-ideas] Re: Barrier Object in asyncio lib

[Jonathan Slenders]

Barry,

What you describe sounds like `asyncio.gather(...)` if I understand
correctly.

The thing with a Barier is that it's usable in situations where we don't
know the other tasks. Maybe there is no reference to them from the current
scope. Maybe they are even not yet created.
It certainly can be done with a list of `asyncio.Future` and
`asyncio.gather(...)`, but that's a lot of boilerplate.

IMHO, Yves is right. For both asyncio and threading, we have Lock, Event,
Condition, Semaphore and BoundedSemaphore. Only Barier is missing among the
asyncio primitives. (RLock doesn't make sense.)
(I guess we can probably go to bugs.python.org with this proposal.)

Jonathan






Le jeu. 25 févr. 2021 à 23:38, Barry Scott  a
écrit :

>
>
> On 25 Feb 2021, at 17:15, Jonathan Slenders  wrote:
>
> It does make sense to have a barrier synchronization primitive for asyncio.
> The idea is to make a coroutine block until at least X coroutines are
> waiting to enter the barrier.
> This is very useful, if certain actions need to be synchronized.
>
>
> I do most of my async coding with twisted where what you calling a barrier
> is a DeferredList.
>
> The way its used is that you add in all the deferreds that you want to
> complete before you continue
> into the list. Once all the deferered have competed the DefferedList
> completes and its callback is run.
>
> Barry
>
>
>
> Recently, I had to implement a barier myself for our use case. See code
> below:
>
> It is simple to implement, but I too would like to have one for asyncio,
> in order to be consistent with the concurrency primitives we have for
> threading.
>
> Jonathan
>
>
> class Barier:
> """
> Make a coroutine block until there are at least X waiters.
>
> Similar to the threading Barier objects but for asyncio:
> https://docs.python.org/3/library/threading.html#barrier-objects
> """
>
> def __init__(self, parties: int) -> None:
> self.parties = parties
> self._waiting: int
> self._event = asyncio.Event()
>
> def add_one(self) -> None:
> self._waiting += 1
> if self._waiting == self.parties:
> self._event.set()
>
> async def wait(self, worker: "Worker") -> None:
> """
> Wait until all we have at least `parties` waiters.
> """
> self.add_one()
> await self._event.wait()
>
>
>
>
> Le jeu. 25 févr. 2021 à 16:42, Barry Scott  a
> écrit :
>
>>
>>
>> > On 25 Feb 2021, at 13:14, Yves Duprat  wrote:
>> >
>> > Hi,the list,
>> >
>> > I'm wondering why Barrier object does not exist in the synchronization
>> primitives of the asyncio lib while it is present in threading and
>> multiprocessing libs ?
>> > This may not be the right place to ask this question, but I never found
>> an answer on the web.
>> > Thanks for your help.
>>
>>
>> I'm assuming that the barrier you are speaking of is the mechanism that
>> is used to
>> synchronise threads/processes running in parallel to prevent data races.
>>
>> With async code that is never an issue. Each function runs to completion
>> uninterrupted.
>> There are no data races. Each time a async function runs it can know that
>> the state of
>> the objects it uses will not be changed while it is running.
>>
>> Barry
>>
>>
>>
>> >
>> > Yves
>> > ___
>> > Python-ideas mailing list -- python-ideas@python.org
>> > To unsubscribe send an email to python-ideas-le...@python.org
>> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> > Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/IAFAH7PWMUDUTLXYLNSXES7VMDQ26A3W/
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>> >
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/B6WDPXNZH5KYK2BLHJXUFZF2DLFBLCBR/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Q74V5X7FGPGZ6BC2C6MHV6D65JH3IE4H/
Code of Conduct: http://python.org/psf/codeofconduct/