<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, May 13, 2018 at 4:30 PM Nick Malaguti <<a href="mailto:python@fwdaddr.fastmail.fm">python@fwdaddr.fastmail.fm</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think Peter tried to outline this earlier, but what he was laying out wasn't clear to me at first.<br>
<br>
There seem to be 4 variations when it comes to assignment expressions. I'm going to try to ignore exact keywords here since we can sort those out once we have settled on which variation we prefer.<br>
<br>
1. infix: TARGET := EXPR<br>
2. infix: EXPR as TARGET<br>
3. prefix: let TARGET = EXPR in ANOTHER_EXPR<br>
4. postfix: ANOTHER_EXPR given TARGET = EXPR<br>
<br>
Both 1 and 2 may appear in the context of a larger expression where TARGET may or may not be used:<br>
<br>
1. 99 + (TARGET := EXPR) ** 2 + TARGET<br>
2. 99 + (EXPR as TARGET) ** 2 + TARGET<br>
<br>
3 and 4 require that TARGET appear in ANOTHER_EXPR, even if TARGET is the only thing contained in that expression, whereas with 1 and 2, TARGET need not be used again.<br>
<br>
Example I:<br>
<br>
1. x := 10<br>
2. 10 as x<br>
3. let x = 10 in x<br>
4. x given x = 10<br>
<br>
In the simple case where the goal of the assignment expression is to bind the EXPR to the TARGET so that TARGET can be used in a future statement, 1 and 2 are clearly the most straightforward because they do not require ANOTHER_EXPR.<br>
<br>
# Please ignore that m.group(2) doesn't do anything useful here<br>
<br>
Example II:<br>
<br>
1. if m := re.match(...): m.group(2)<br>
2. if re.match(...) as m: res = m.group(2)<br>
3. if let m = re.match(...) in m: m.group(2)<br>
4. if m given m = re.match(...): m.group(2)<br>
<br>
I also think expressions that use "or" or "and" to make a compound expression benefit from the infix style, mostly because each sub-expression stands on its own and is only made longer with the repetition of TARGET:<br>
<br>
Example III:<br>
<br>
1. if (diff := x - x_base) and (g := gcd(diff, n)) > 1: ...<br>
2. if (x - x_base as diff) and (gcd(diff, n) as g) > 1: ...<br>
3. if (let diff = x - x_base in diff) and (let g = gcd(diff, n) in g > 1): ...<br>
4. if (diff given diff = x - x_base) and (g > 1 given g = gcd(diff, n)): ...<br>
<br>
In the more complex case where TARGET is reused in the expression, I find 3 and 4 to benefit as there is a separation of the binding from its usage. I can consider each expression separately and I don't have to deal with the assignment side effects at the same time. I believe this is what Neil is mostly arguing for.<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
# Borrowing from Andre, please forgive any mathematical problems like division by 0<br>
<br>
Example IV:<br>
<br>
1: [(-b/(2*a) + (D := sqrt( (b/(2*a))**2 - c/a), -b/(2*a) - D) <br>
for a in range(10) <br>
for b in range(10)<br>
for c in range(10)<br>
if D >= 0]<br>
2: [(-b/(2*a) + (sqrt( (b/(2*a))**2 - c/a as D), -b/(2*a) - D) <br>
for a in range(10) <br>
for b in range(10)<br>
for c in range(10)<br>
if D >= 0]<br>
3. [let D = sqrt( (b/(2*a))**2 - c/a) in <br>
(-b/(2*a) + D, -b/(2*a) - D) <br>
for a in range(10) <br>
for b in range(10)<br>
for c in range(10)<br>
if D >= 0]<br>
4. [(-b/(2*a) + D, -b/(2*a) - D) <br>
for a in range(10) <br>
for b in range(10)<br>
for c in range(10)<br>
if D >= 0<br>
given D = sqrt( (b/(2*a))**2 - c/a)]<br>
<br>
Also in the case with multiple bindings I find that 3 and 4 benefit over 1 and 2:<br>
<br>
Example V:<br>
<br>
1. [(x := f(y := (z := f(i) ** 2) + 1)) for i in range(10)]<br>
2. [(f((f(i) ** 2 as z) + 1 as y) as x) for i in range(10)]<br>
3. [let x = f(y), y = z + 1, z = f(i) ** 2 in x for i in range(10)] # maybe the order of the let expressions should be reversed?<br>
4. [x given x = f(y) given y = z + 1 given z = f(i) ** 2 for i in range(10)]<br>
<br>
No matter which variation we prefer, there are plenty of arguments to be made that multiple assignment expressions in a single expression or usage of the TARGET later in the expression is harder to work with in most cases,. And since 1 and 2 (at least to me) are more difficult to parse in those situations, I'm more likely to push back on whoever writes that code to do it another way or split it into multiple statements.<br>
<br>
I feel that Steven prefers 1, mostly for the reason that it makes Examples I, II, and III easier to write and easier to read. Neil prefers 4 because Examples I, II, and II still aren't that bad with 4, and are easier to work with in Examples IV and V.<br>
<br>
If you feel that Examples IV and V should be written differently in the first place, you probably prefer infix (1 or 2).<br>
<br>
If you feel that Examples IV and V are going to be written anyway and you want them to be as readable as possible, you probably prefer prefix (3) or postfix (4).<br>
<br>
If you want to know what all the TARGETs are assigned to up front, you probably prefer 1 or 3 (for reading from left to right).<br>
<br>
If you want to see how the TARGET is used in the larger expression up front and are willing to read to the end to find out if or where the TARGET has been defined, you probably prefer 4.<br>
<br>
In my mind, all 4 variations have merit. I think I prefer prefix or postfix (postfix feels very natural to me) because I believe more complex expressions should be separateable (Neil argues better than I can for this).<br>
<br>
But Steven has gone a long way to convince me that the sky won't fall if we choose an infix variation because in practice our better angels will push us away from using expressions that are too complex.<br>
<br>
Prefix vs postfix is a discussion worth having if we decide that infix isn't the right choice.<br>
<br>
I would love to see us reach consensus (too optimistic?) or at least an acknowledgment of the explicit tradeoffs for whichever variation we ultimately choose.<br></blockquote><div><br></div><div>In my mind, your given clauses are upside-down. The way I see it, code like this: </div><div><br></div><div><div>for a in range(10):</div><div> if a != 5:</div><div> for b in range(10):</div><div> for c in range(10):</div><div> D = sqrt((b/(2*a))**2 - c/a)</div><div> if D >= 0:</div><div> yield (-b/(2*a) + D, -b/(2*a) - D) </div></div><div><br></div><div>should be cast into a generator like this:</div><div><br></div><div><div>((-b/(2*a) + D, -b/(2*a) - D) </div><div> for a in range(10)</div><div> if a != 5</div><div> for b in range(10)</div><div> for c in range(10)</div><div> given D = sqrt( (b/(2*a))**2 - c/a)</div><div> if D >= 0)</div></div><div><br></div><div>Just leave everything in the order you wrote it except the yield statement turns into a bare expression in front.</div><div><br></div><div>Regarding prefix versus postfix, we already do postfix binding using "for" clauses and I want to be able to interleave given clauses with for clauses as above to prevent a bracketing mess that prefix would require.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
Nick<br>
<br>
----- Original message -----<br>
From: Matt Arcidy <<a href="mailto:marcidy@gmail.com" target="_blank">marcidy@gmail.com</a>><br>
To: Brendan Barnwell <<a href="mailto:brenbarn@brenbarn.net" target="_blank">brenbarn@brenbarn.net</a>><br>
Cc: "python-ideas" <<a href="mailto:python-ideas@python.org" target="_blank">python-ideas@python.org</a>><br>
Subject: Re: [Python-ideas] Inline assignments using "given" clauses<br>
Date: Sun, 13 May 2018 11:53:20 -0700<br>
<br>
<br>
<br>
On Sun, May 13, 2018, 11:28 Brendan Barnwell <<a href="mailto:brenbarn@brenbarn.net" target="_blank">brenbarn@brenbarn.net</a>> wrote:<br>
> On 2018-05-13 04:23, Steven D'Aprano wrote:<br>
> > In my experience mathematicians put the given *before* the statement:<br>
> ><br>
> > Given a, b, c three sides of a triangle, then<br>
> ><br>
> > Area = sqrt(s*(s-a)*(s-b)*(s-c))<br>
> ><br>
> > where s = (a + b + c)/2 is the semi-perimeter of the triangle.<br>
> ><br>
> > For the record, that is almost exactly what I wrote for a student<br>
> > earlier today, and its not just me, it is very similar to the wording<br>
> > used on both Wolfram Mathworld and Wikipedia's pages on Heron's Formula.<br>
> ><br>
> > <a href="http://mathworld.wolfram.com/HeronsFormula.html" rel="noreferrer" target="_blank">http://mathworld.wolfram.com/HeronsFormula.html</a><br>
> ><br>
> > <a href="https://en.wikipedia.org/wiki/Heron%27s_formula" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Heron%27s_formula</a><br>
> ><br>
> ><br>
> > Putting "given" after the expression is backwards.<br>
> <br>
> Yes, but that's because we're ruling out the use of "where". At this <br>
> point I would be fine with "snicklefritz" as the keyword. The point is <br>
> that I want to put SOMETHING after the expression, and this is not at <br>
> all unusual. See for instance Wikipedia pages on the Reimann zeta <br>
> function <br>
> (<a href="https://en.wikipedia.org/wiki/Riemann_zeta_function#Definition" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Riemann_zeta_function#Definition</a>), <br>
> gravitation equation <br>
> (<a href="https://en.wikipedia.org/wiki/Gravity#Newton%27s_theory_of_gravitation" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Gravity#Newton%27s_theory_of_gravitation</a>), and <br>
> compound interest <br>
> (<a href="https://en.wikipedia.org/wiki/Compound_interest#Mathematics_of_interest_rate_on_loans" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Compound_interest#Mathematics_of_interest_rate_on_loans</a>). <br>
> If we have to use the word "given" even though the word mathematicians <br>
> would use in that position is "where", that's not such a big deal.<br>
<br>
it is a big deal. postfix requires more cognitive load, we will have no idea up front what's going on except for trivial exames. more givens, more cognitive load.<br>
<br>
if you think spending that is fine for you, I can't argue, but to say it doesn't matter isn't correct.<br>
<br>
2.exames which get far worse for complex cases. left for the for can be as complex.as.you wish.<br>
1:<br>
[ x + y for t in range(10) ... ]<br>
<br>
2:<br>
x = 10<br>
y = 20<br>
[ x + y for t in range(10) ...]<br>
<br>
up till you read ... you have no idea there even will be a substitution. The lower is even worse, you think you know, but then have to redo the whole problem with new information.<br>
<br>
also :<br>
mathematicians don't just put the _word_ "given", they put givens, things that are known or assumed to be true. Axioms and definitions, where definitions assign names to values. This is for formal arguements. reassigning values is handled in post fix occasionally once it is clear what x and y are. but that's not what we are talking about if the name doesn't exist already.<br>
<br>
again, you want to use given, that's fine, but the math argument is wrong, as is the "it doesn't matter" argument, assuming the current neurological model for working memory continues to hold.<br>
<br>
Maybe the difference is small, especially after familiarity sets in, but that doesn't mean the difference in load isn't there. it will only increase for more complex statements with more givens.<br>
> <br>
> --<br>
> Brendan Barnwell<br>
> "Do not follow where the path may lead. Go, instead, where there is no <br>
> path, and leave a trail."<br>
> --author unknown<br>
> _______________________________________________<br>
> Python-ideas mailing list<br>
> <a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
> Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
_________________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
<br>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group.<br>
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/python-ideas/CFuqwmE8s-E/unsubscribe" rel="noreferrer" target="_blank">https://groups.google.com/d/topic/python-ideas/CFuqwmE8s-E/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href="mailto:python-ideas%2Bunsubscribe@googlegroups.com" target="_blank">python-ideas+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" rel="noreferrer" target="_blank">https://groups.google.com/d/optout</a>.<br>
</blockquote></div></div>