[Python-ideas] Re: Conditional 1-line expression in python

[Chris Angelico]

On Fri, 21 Jul 2023 at 11:08, Dom Grigonis  wrote:
> Also, can't find a way to ONLY force evaluation without any additional 
> operations in this specific library. A simple callable which evaluates if 
> unevaluated & returns would do. Then:
>
> def IF(condition, when_true, when_false):
> if condition:
> return ensure_eval(when_true)
> else:
> return ensure_eval(when_false)
>
> Controls evaluation if deferred objects are provided, but can also be used 
> with `normal` values.
>

Let's tackle just this one part for a moment. What does "ensure_eval"
do? Evaluate a proxy object but not evaluate anything else? That seems
simple, but might very well be straight-up wrong. Consider:

def test_proxy(x):
x_ = Proxy(x)
y = ensure_eval(x_)
y_ = ensure_eval(y)
assert x is y
assert x is y_

This should always succeed, right? Well, what if x is itself a Proxy
object? How does it know not to reevaluate it?

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

[Python-ideas] Re: Conditional 1-line expression in python

[Dom Grigonis]

That is where I got to really. Ability to construct one’s own expressions, 
where evaluation can be controlled. And found out that deferred evaluation is 
what would potentially provide exactly what is needed for this.

Making use of ‘function’ protocol seems appropriate as I don’t think inventing 
any extensive syntax is justified.
from lazy_object_proxy import Proxy

value = Proxy(lambda: expr())
# If this could be written in a more concise form. e.g.:
value = `expr()`
# then it would be worthwhile constructing and making use of VB-like expressions
def IF(condition, when_true, when_false):
if condition:
return when_true
else:
return when_false

def expr1():
print('__expr1__')
return 1

def expr2():
print('__expr2__')
return 2

result = IF(True, `expr1()`, `expr2()`)
# Expressions would only be evaluated when certain usage takes place

# This works fairly nicely, but inconvenience of it is a dealbreaker (to be 
used for such cases)
result = IF(True, Proxy(lambda: expr1()), Proxy(lambda: expr2()))
# Not yet evaluated
print(result + 1)
# Now it is
Also, can't find a way to ONLY force evaluation without any additional 
operations in this specific library. A simple callable which evaluates if 
unevaluated & returns would do. Then:
def IF(condition, when_true, when_false):
if condition:
return ensure_eval(when_true)
else:
return ensure_eval(when_false)
Controls evaluation if deferred objects are provided, but can also be used with 
`normal` values.

> On 20 Jul 2023, at 22:51, Random832  wrote:
> 
> On Mon, Jul 17, 2023, at 16:41, Dom Grigonis wrote:
>> Would be interesting to see if my preference is an outlier or not really.
> 
> I think this is a false dichotomy. We should consider VB-like conditional 
> expressions if(condition, when_true, when_false) as well.
> ___
> 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/FZBHN6DVTH2IW4OZH4R36EYZWRRMEYJL/
> 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/QISXXUFM6NJJHR3O6MPOWRTS5BQSZM3J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Conditional 1-line expression in python

[Chris Angelico]

On Fri, 21 Jul 2023 at 05:53, Random832  wrote:
>
> On Mon, Jul 17, 2023, at 16:41, Dom Grigonis wrote:
> > Would be interesting to see if my preference is an outlier or not really.
>
> I think this is a false dichotomy. We should consider VB-like conditional 
> expressions if(condition, when_true, when_false) as well.
>

Why? That sort of expression would be syntactically a function call,
which you can already create, but which would eagerly evaluate both
its arguments. The entire value of an actual conditional expression is
that it WON'T evaluate the expression it isn't using.

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

[Python-ideas] Re: Conditional 1-line expression in python

[Random832]

On Mon, Jul 17, 2023, at 16:41, Dom Grigonis wrote:
> Would be interesting to see if my preference is an outlier or not really.

I think this is a false dichotomy. We should consider VB-like conditional 
expressions if(condition, when_true, when_false) as well.
___
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/FZBHN6DVTH2IW4OZH4R36EYZWRRMEYJL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Chris Angelico]

On Thu, 20 Jul 2023 at 22:27, Stephen J. Turnbull
 wrote:
>
> Chris Angelico writes:
>  > On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull
>  >  wrote:
>
> C'mon Chris, "that was then, this is now".  Catch up, I've changed my
> position. ;-)
>

That's fair :) Maybe I'll dust off that proposal again at some point.

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

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Stephen J. Turnbull]

Chris Angelico writes:
 > On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull
 >  wrote:

C'mon Chris, "that was then, this is now".  Catch up, I've changed my
position. ;-)

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

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

Ok, this is tricky.
So pretty much impossible, given that `Break`, if it was to work has to be 
evaluated in reference scope, while other delayed objects in their definition 
scope.

--
Back to deferred evaluation.

--
Giving it a rest for a while. Thank you for your patience.


> On 20 Jul 2023, at 12:38, Chris Angelico  wrote:
> 
> On Thu, 20 Jul 2023 at 19:34, Dom Grigonis  wrote:
>> And ideally, adding 2 builtin(or imported from stdlib) functions: `Break` 
>> and `Continue`, which if called act as `break` and `continue` statements.
>> 
> 
> How would they work? Would every function call have to provide the
> possibility to return to a location that wasn't where you would
> otherwise go?
> 
> if random.randrange(2):
>func = Break
> else:
>def func(): pass
> 
> def wut():
>for i in range(1, 10):
>if i % 3: func()
>print(i)
> 
> wut()
> 
> Please, tell me how this would behave.
> 
> ChrisA

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

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Chris Angelico]

On Thu, 20 Jul 2023 at 19:34, Dom Grigonis  wrote:
> And ideally, adding 2 builtin(or imported from stdlib) functions: `Break` and 
> `Continue`, which if called act as `break` and `continue` statements.
>

How would they work? Would every function call have to provide the
possibility to return to a location that wasn't where you would
otherwise go?

if random.randrange(2):
func = Break
else:
def func(): pass

def wut():
for i in range(1, 10):
if i % 3: func()
print(i)

wut()

Please, tell me how this would behave.

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

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

I have looked more properly at deferred evaluation and late-bound defaults. 
Deferred-eval is overkill for what I need and isn’t likely to come about soon, 
while deferred only solves a very small part of what I am looking at. Also, it 
lacks ability to enforce default from outside, which is a bit of a dealbreaker 
to me.

Sooo…

I have come up to a conclusion that what would shut me up is a shorthand syntax 
for lambda. Either:
1) Ability to assign it to a different name
or MUCH MORE preferably
2) lambda: expr() == `expr()` == ?(expr()) == ???. Anything concise and 
sensible would do.

lambda pretty much does the trick, but syntax is too awkward to use for such 
applications.

And ideally, adding 2 builtin(or imported from stdlib) functions: `Break` and 
`Continue`, which if called act as `break` and `continue` statements.

> On 20 Jul 2023, at 11:11, Greg Ewing  wrote:
> 
> On 20/07/23 6:30 pm, James Addison via Python-ideas wrote:
>>result = default if bar is None else bar
>>or if you prefer
>>result = bar if bar is not None else default
> 
> Would it shut anyone up if we had another logical operator:
> 
>x otherwise y
> 
> equivalent to
> 
>x if x is not None else y
> 
> ?
> 
> -- 
> Greg
> 
> ___
> 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/R55FL6U5RFMPLP6NWE4IMMLNR4OLVGTF/
> 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/EX7B7LYIAL6XBPWCCCAC2IYUPVCY7HRJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Chris Angelico]

On Thu, 20 Jul 2023 at 18:16, Greg Ewing  wrote:
>
> On 20/07/23 6:30 pm, James Addison via Python-ideas wrote:
> > result = default if bar is None else bar
> > or if you prefer
> > result = bar if bar is not None else default
>
> Would it shut anyone up if we had another logical operator:
>
>  x otherwise y
>
> equivalent to
>
>  x if x is not None else y
>
> ?
>

https://peps.python.org/pep-0505/

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

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Greg Ewing]

On 20/07/23 6:30 pm, James Addison via Python-ideas wrote:

result = default if bar is None else bar
or if you prefer
result = bar if bar is not None else default


Would it shut anyone up if we had another logical operator:

x otherwise y

equivalent to

x if x is not None else y

?

--
Greg

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

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Chris Angelico]

On Thu, 20 Jul 2023 at 17:09, Dom Grigonis  wrote:
>
> On 20 Jul 2023, at 09:48, anthony.flury  wrote:
> In Python then a better way might be
>
> result = temp := bar() if temp else default
>
> This way only bar() and default are evaluated and invoked once.
>

I presume you want a more complicated expression than just "if temp",
since this is no better than "bar() or default". But if you DO want
some other condition, this would be how you'd write it:

result = temp if (temp := bar()) is None else default

Or, better:

result = bar()
if result is None: result = default

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

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

Thanks, thats truly useful to keep in mind.

> On 20 Jul 2023, at 09:48, anthony.flury  wrote:
> 
> 
> The challenge with anything like 
> 
> result = default if bar is None else bar
> 
> or 
> result = bar if bar else default
> 
> or even 
> 
> result = bar is None ? default : bar
> 
> 
> is that sure default is only evaluated once - but in all cases 'bar' is 
> evaluated twice, and if bar is a function call then no parser is clever 
> enough to diagnose all possible side effects of calling bar() twice, or even 
> detect that bar can be cached, so it will always be called twice.
> 
> In Python then a better way might be 
> 
> result = temp := bar() if temp else default 
> 
> This way only bar() and default are evaluated and invoked once.
> 
> 
> 
> -- Original Message --
> From: "Rob Cliffe via Python-ideas"  >
> To: "Dom Grigonis" mailto:dom.grigo...@gmail.com>>; 
> "Jothir Adithyan" mailto:adithyanjot...@gmail.com>>
> Cc: python-ideas@python.org 
> Sent: Monday, 17 Jul, 23 At 16:09
> Subject: [Python-ideas] Re: Proposal for get_or function in Python 
> dictionaries
> 
>  
>  
>  
> On 15/07/2023 21:08, Dom Grigonis   wrote:
>  
>  
>   Just to add. I haven’t thought about evaluation. Thus, to 
> prevent   evaluation of unnecessary code, introduction of C-style 
> expression   is needed anyways:   
>  
>
>  
>
> 1. result = bar   is None ? default : bar
>  
>
>  
>  
> 
>  
>  
> The below would have to evaluate all arguments,   thus not achieving 
> benefits of PEP505.
>  
>
>  
>
> 2. result = ifelse(bar is None, default, bar)
>  
>
>  
>  
> 
>  
>  
> 
>  
>  
> So I would vote for something similar to:
>  
>
>  
>
>  
> result = bar is None ? default : bar
>
>  
>
>  
>  
> 
>  
>  
> Where default and bar is only evaluated if needed. Although   not to 
> the extent as initially intended, it would offer   satisfiable 
> solutions to several proposals.
>  
>
>  
>  Well, default is only evaluated if needed; bar is always evaluated.
>  What is wrong with the Python equivalent
>  
>  result = default if bar is None else bar
>  or if you prefer
>  result = bar if bar is not None else default
>  
>  Perhaps you didn't know about this construction?
>  It does exactly the same as the C version and is more readable.  Or 
> am I missing something?
>  Best wishes
>  Rob Cliffe
>  
> ___
> 
> 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/4QBAYBAT6EZFILNS2MCK3D6XW4LNRDZ5/
>  
> 
> 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> 
> 
> 
> 
> -- Anthony Fluryanthony.fl...@btinternet.com 
> 
___
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/PUKJNAGRRUGW3V4DUWNSQ3BZRLUJH5YT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Chris Angelico]

On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull
 wrote:
> I didn't like that PEP then; I was in the camp of "let's get genuine
> Deferreds, and use them to cover some of the use cases for PEP 671."

You're almost certainly never going to get that, because "genuine
Deferreds", as well as being nearly impossible to pin down, can't
actually cover all the use-cases of PEP 671.

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

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

>   result = bar or default

I used to do this, but dropped this habit. Just to be on the safe side if in 
the future I extend bar to take value for which truth test evaluates to False. 
And for consistency across the codebase.

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

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

> I think that's reasonable.  But I don't think Python is the language
> for that.  There are too much existing contrasts, such as loop vs.
> comprehension and conditional statement vs. ternary expression.  Guido
> deliberately chose to vary those expression syntaxes from their
> statement equivalents.  I don't think there's any ambiguity if you say
> that wrapping a compound statement in parentheses creates an
> expression with restricted syntax (namely, the statements the syntax
> controls become expressions):
> 
>(if condition_1: expression_1
> elif condition_2: expression_2
> else: expression_else)
> 
>[for element in iterable: if condition: expression(element)]
> 
> But Guido (and I think everybody else) thought "N! not *that*!”


Yes, I realise that there is no way back as different direction has already 
been taken. So I am not (and have not been) proposing any changes there, just 
trying to find ways to get to where I would like to with python.

>> ??
>> `Deferred evaluation`, if was to gain traction in a similar manner
>> as e.g. `annotations` are now experiencing, would cover all of the
>> cases I was looking at & more.
> 
> As Chris was saying earlier, it's at minimum going to take some genius
> creativity to "cover all and more", because a closer look at what
> people mean by "deferred" shows that in different cases it is
> semantically different.  In particular, there are a number of choices
> that Chris made in PEP 671 that aren't compatible with several of the
> proposals for Deferred objectss, while Deferreds can't give some of
> the benefits of the PEP.

I have read both PEP671 and 
https://github.com/DavidMertz/peps/blob/master/pep-.rst 
, but can’t see 
what benefits does PEP provide, that def-eval can not. I see that they are not 
the same in implementation even orthogonal, but it seems that PEP671, maybe not 
as elegantly, but can achieve the same result.

> I didn't like that PEP then; I was in the camp of "let's get genuine
> Deferreds, and use them to cover some of the use cases for PEP 671."
> I don't actively want the PEP now.  def-time evaluation of defaults
> doesn't catch me and I haven't had trouble teaching it.  The
> "if arg is None: arg = Mutable()" idiom is rare enough that I prefer
> it to adding syntax to the already complex function prototype.

That idiom is only 1 example. See my e-mail with examples of how def-eval 
relates to several PEPs and requests that came up recently in this group. It 
would improve things in many areas. E.g. infix operators might become an 
actually useful thing instead of being just a cool thing to take a look at. 
IMO, infix pattern is too cumbersome to be used as actual operator, but would 
be perfect for defining binary and maybe ternary expressions.

If it’s usage would be as in “def-eval rst", it would potentially bring about a 
new paradigm to the way I do things. Especially if it was well optimised and 
had a concise syntax.
# something similar to
`expr`
# or
?(expr)
> But if you think it might be a good idea, I encourage you to take a
> close look.  For some use cases it's definitely an improvement, and at
> least I won't vocally oppose the PEP now -- haven't seen any progress
> on "true Deferreds".  Perhaps others' opposition has softened, too.
> Adding another proponent is another way to help get it going again.

I am not sure if I would be the right person for this, but if you know any good 
places (discussions or attempts) to look at apart from that “def-eval rst”, I 
would take a look. So far I am only excited about it from user’s perspective…

DG

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

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[James Addison via Python-ideas]

On Thu, Jul 20, 2023, 01:19 Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:

>
>
> On 15/07/2023 21:08, Dom Grigonis wrote:
>
> Just to add. I haven’t thought about evaluation. Thus, to prevent
> evaluation of unnecessary code, introduction of C-style expression is
> needed anyways:
>
> 1. result = bar is None ? default : bar
>
>
> The below would have to evaluate all arguments, thus not achieving
> benefits of PEP505.
>
> 2. result = ifelse(bar is None, default, bar)
>
>
>
> So I would vote for something similar to:
>
> result = bar is None ? default : bar
>
>
> Where default and bar is only evaluated if needed. Although not to the
> extent as initially intended, it would offer satisfiable solutions to
> several proposals.
>
> Well, default is only evaluated if needed; bar is always evaluated.
> What is wrong with the Python equivalent
>
> result = default if bar is None else bar
> or if you prefer
> result = bar if bar is not None else default
>

Note also that when the condition is a truthiness check -- admittedly not
always the case, but it does occur reasonably often -- this can be
simplified further to:

  result = bar or default

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