<div dir="auto"><div>In 20 years of programming Python, I have never wanted to augment two distinct variables by two distinct return values from a function.</div><div dir="auto"><br></div><div dir="auto">I'm sure it's possible to construct some situation where that would be convenient, and presumably the OP actually encountered that. But the need is exceedingly rare, and absolutely not worth enabling syntax that is confusing in other ways and introduces inconsistencies in overall semantics.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Thu, Aug 30, 2018, 8:16 PM James Lu <<a href="mailto:jamtlu@gmail.com">jamtlu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">> <span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">Rather,</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">> </div>because Python has become a big and very complete programming<br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">> </div>environment, and a fairly large language, implementing new syntax<br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">> </div>requires that a feature increase expressiveness substantially.<div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">That makes sense.</div></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">> <span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">By comparison,</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">> <span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"> x, y += a, b</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">> </div>is neither more expressive, nor easier to read, nor significantly</div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">> </div>harder to type, than<br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">></div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline"></div> x += a<br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">></div> y += b <br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I agree. I contend that x, y += func(...) is more readable than the three-</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">statement alternative with a namespace pollution.<br></div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 28, 2018 at 4:05 AM Stephen J. Turnbull <<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp" target="_blank" rel="noreferrer">turnbull.stephen.fw@u.tsukuba.ac.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Executive summary: Much of this is my opinion, and as a newer poster,<br>
your opinion is *more* valuable than mine (fresh eyes and all that).<br>
What I hope you'll take from this post is a more precise understanding<br>
of the customary criteria that are used in evaluating a proposed<br>
feature on python-ideas and python-dev.<br>
<br>
Apologies for breaking the thread, but per Subject it's not really part<br>
of the thread.<br>
<br>
James Lu writes:<br>
<br>
> I could, but I don't think that justifies not having this<br>
> functionality in python standard.<br>
<br>
What's "this"? Note:<br>
<br>
>> When replying, please edit your Subject line so it is more specific<br>
>> than "Re: Contents of Python-ideas digest..."<br>
<br>
I had to edit the Subject. I'm going to assume you mean<br>
<br>
>> 1. Re: Unpacking iterables for augmented assignment (Matthew Einhorn)<br>
<br>
So. The Python development community generally doesn't require<br>
justification for refusing to implement new functionality. Rather,<br>
because Python has become a big and very complete programming<br>
environment, and a fairly large language, implementing new syntax<br>
requires that a feature increase expressiveness substantially.<br>
<br>
In the case in point, the destructuring assignments<br>
<br>
a, b = b, a<br>
w, x, y, z = z, w, y, x<br>
<br>
can be interpreted as "swapping" or "permuting", and AIUI that's why<br>
they were included. They express the intent better than<br>
<br>
tmp = a<br>
a = b<br>
b = tmp<br>
del tmp<br>
<br>
and I don't want to even think about how to do the 4-variable version<br>
without 4 temporary variables. By comparison,<br>
<br>
x, y += a, b<br>
<br>
is neither more expressive, nor easier to read, nor significantly<br>
harder to type, than<br>
<br>
x += a<br>
y += b<br>
<br>
as far as I can see. Note that this is the "not harder to type"<br>
criterion normally used in discussing new Python features, not<br>
something I've invented.<br>
<br>
> This is something I think most students will expect while learning<br>
> python, especially if they're implementing algorithms.<br>
<br>
I suppose this claim is unlikely to be accepted without testimony of<br>
several teachers of Python. In my own experience, I explicitly teach<br>
my students that the destructuring assignment is *for* permuting, and<br>
I have *not even once* been asked if it works for augmented<br>
assignments. By contrast, students with knowledge of other languages<br>
(especially C-like languages) invariably "just use" augmented<br>
assignments and ask if there's some spelling for increment and<br>
decrement expressions. Obviously, my teaching approach biases the<br>
result, but if nobody ever overcomes that bias, I do not think it is<br>
an expected or needed feature.<br>
<br>
Steve<br>
<br>
</blockquote></div>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank" rel="noreferrer">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer 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 noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div></div></div>