<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#000000">Minor gripe: The ability to <i>articulate</i> Python is not the same as the ability to <i>type Python verbally</i>.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#000000">Nobody articulates `def area(width, height): return width * height` as <i>def area, open paren, width, comma, space, height, closed paren..</i>.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#000000">They would say something like <i>def area as a function of width and height, equal to width by height</i>.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(115,115,115);font-style:italic;line-height:18px"><font size="1" face="monospace, monospace">-- Carl Smith</font></span><br></div></div><div><span style="color:rgb(115,115,115);font-style:italic;line-height:18px"><font size="1" face="monospace, monospace"><a href="mailto:carl.input@gmail.com" target="_blank">carl.input@gmail.com</a></font></span></div></div></div></div></div></div>
<br><div class="gmail_quote">On 12 May 2018 at 18:24, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, May 12, 2018 at 08:16:07AM -0700, Neil Girdhar wrote:<br>
<br>
> I love given compared with := mainly because<br>
> <br>
> Simpler is better than complex:<br>
> * given breaks a complex statement into two simpler ones,<br>
<br>
</span>(Foreshadowing: this argument applies to augmented assignment. See <br>
below.)<br>
<br>
I don't see how you justify that statement about "given". I think that <br>
it is "given" which is more complex. Significantly so.<br>
<br>
Let's compare the syntax:<br>
<br>
    target := expr<br>
<br>
<br>
That is a single, simple expression with a single side-effect: it <br>
assigns the value to <target>. That's it.<br>
<br>
Like all expressions, it returns a value, namely the result of "expr". <br>
Like all expressions, you can embed it in other expressions (possibly <br>
wrapping it in parens to avoid precedence issues), or not, as required.<br>
<br>
(That surrounding expression can be as simple or complex as you like.)<br>
<br>
<br>
Now here's Nick's syntax:<br>
<br>
    target given target = expr<br>
<br>
Exactly like the := version above, we can say that this is a single <br>
expression with a single side-effect. Like all expressions, it returns a <br>
value, namely the result of "expr", and like all expressions, you can <br>
embed it in other expressions.<br>
<br>
So far the two are precisely the same. There is no difference in the<br>
complexity, because they are exactly the same except for the redundant <br>
and verbose "given" spelling.<br>
<br>
But actually, I lied.<br>
<br>
Nick's syntax is *much more complicated* than the := syntax. Any <br>
arbitrary expression can appear on the left of "given". It need not <br>
even involve the binding target! So to make a fair comparison, I ought <br>
to compare:<br>
<br>
    target := expr<br>
<br>
which evaluates a single expression, binds it, and returns it, to:<br>
<br>
    another_expr given target := expr<br>
<br>
which evaluates "expr", binds it to "target", evaluates a SECOND<br>
unrelated expression, and returns that.<br>
<br>
If you want to argue that this is more useful, then fine, say so. But to <br>
say that it is *simpler* makes no sense to me.<br>
<br>
Option 1: evaluate and bind a single expression<br>
<br>
Option 2: exactly the same as Option 1, and then evaluate a second<br>
expression<br>
<br>
How do you justify that Option 2 "given", which does everything := does <br>
PLUS MORE, is simpler than Option 1?<br>
<br>
That's not a rhetorical question.<br>
<span class=""><br>
<br>
<br>
> which is putting people off in the simple examples shown here (some <br>
> people are annoyed by the extra characters).  However, when given is <br>
> used in a list comprehension to prevent having to re-express it as a <br>
> for loop, then two simple statements are easier to understand than one <br>
> complex statement.<br>
<br>
</span>I'd like to see an example of one of these list comprehensions that is <br>
simpler written with given. Here's an earlier example, an exponentially <br>
weighted running average:<br>
<br>
<br>
average = 0<br>
smooth_signal = [(average := (1-decay)*average + decay*x) for x in signal]<br>
assert average == smooth_signal[-1]<br>
<br>
<br>
I'm not even sure if "given" will support this. Nick is arguing strongly <br>
that bound targets should be local to the comprehension, and so I think <br>
you can't even write this example at all with Nick's scoping rule.<br>
<br>
But let's assume that the scoping rule is the same as the above. In that <br>
case, I make it:<br>
<br>
average = 0<br>
smooth_signal = [average given average = (1-decay)*average + decay*x) for x in signal]<br>
<br>
Is it longer, requiring more typing? Absolutely.<br>
<br>
Does it contain a redundantly repetitious duplication of the repeated <br>
target name? Certainly.<br>
<br>
But is it simpler? I don't think so.<br>
<br>
<br>
If you don't like the exponential running average, here's a simple <br>
running total:<br>
<br>
<br>
total = 0<br>
running_totals = [total := total + x for x in xs]<br>
<br>
<br>
versus<br>
<br>
<br>
total = 0<br>
running_totals = [total given total = total + x for x in xs]<br>
<br>
<br>
If you don't like this example either, please show me an example of an <br>
actual list comp that given makes simpler.<br>
<span class=""><br>
<br>
> This is a <br>
> common difference between code written at programming contests versus code <br>
> written by those same software engineers years later at big companies.  <br>
> Code that you write for yourself can be compact because you already <br>
> understand it, but code you write professionally is read many many more <br>
> times than it is written.  Accessibility is much more important than <br>
> concision. <br>
<br>
</span>Ah, nice rhetorical argument: "given" is for professionals, := is a hack <br>
for amateurs and programming contests. Seriously?<br>
<br>
Do you use augmented assignment? Your simple versus complex argument for <br>
"given" applies well to augmented assignment.<br>
<br>
Augmented assignment combines two conceptual operations:<br>
<br>
    x = x + 1<br>
    - addition (for example)<br>
    - assignment<br>
<br>
into a single operator:<br>
<br>
    x += 1<br>
<br>
<br>
By your argument, augmented assignment is more complex, and we ought to <br>
prefer splitting it into two separate operations x = x + 1 because <br>
that's simpler.<br>
<br>
I think I agree that x = x + 1 *is* simpler. We can understand it by <br>
understanding the two parts separately: x+1, followed by assignment.<br>
<br>
Whereas += requires us to understand that the syntax not only calls a <br>
dunder method __iadd__ (or __add__ if that doesn't exist), which <br>
potentially can operate in place, but it also does an assignment, all in <br>
one conceptual operation. There's a whole lot of extra complexity there.<br>
<br>
That doesn't mean I agree with your conclusion that we ought to prefer <br>
the simpler version, let alone that the complex case (augmented <br>
assignment) is fit only for programming contests and that professionals <br>
ought to choose the simpler one.<br>
<span class="im HOEnZb"><br>
<br>
<br>
-- <br>
Steve<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
</span><div class="HOEnZb"><div class="h5"><a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</div></div></blockquote></div><br></div>