<div dir="ltr">I think I "get" what Thomas is talking about here:<div><br></div><div>Starting with the simplest example, when defining a function, you can have one take a single positional parameter:</div><div><br></div><div>def fun(x):</div><div>    ...</div><div><br></div><div>and you can have code all over the place that calls it:</div><div><br></div><div>fun(something)</div><div><br></div><div>Later on, if you want to exapand the API, ytou can add a keyword parameter:</div><div><br></div><div>def fun(x, y=None):</div><div>    ...</div><div><br></div><div>And all the old code that already calls that function with one argument still works, and newer code can optionally specify the keyword argument -- this is a really nice feature that makes Python very refactorable. </div><div><br></div><div>But for return values, there is no such flexibility -- if you have already written your function with the simple API:</div><div><br></div><div>def fun(...):</div><div>    ...</div><div>    return something</div><div><br></div><div>And it is being used already as such:</div><div><br></div><div>x = fun()</div><div><br></div><div>Then you decide that an optional extra return value would be useful, and you re-write your function:</div><div><br></div><div>def fun(...):</div><div>    ...</div><div>    return something, something_optional</div><div><br></div><div>now all the call locations will need to be updated:</div><div><br></div><div>x, y = fun()</div><div><br></div><div>or maybe:</div><div><br></div><div>x, __ = fun()</div><div><br></div><div>Sure, if you had had the foresight, then you _could_ have written your original function to return a more flexible data structure (dict, NamedTuple, etc), but, well, we usually don't have that foresight :-).</div><div><br></div><div>My first thought was that function return tuples, so you could document that your function should be called as such:</div><div><br></div><div>x = fun()[0]</div><div><br></div><div>but, alas, tuple unpacking is apparently automatically disabled for single value tuples  (how do you distinguish a tuple with a single value and the value itself??) . so you could do this if you started with two or more return values:</div><div><br></div><div>x, y = fun()[:2]</div><div><br></div><div>OR you could hae your original function return a len-1 tuple in the first place:</div><br>def test(): <br>     return (5,)<br><br><div>but then that would require the same foresight.<br><div><br></div><div>So: IIUC, Thomas's idea is that there be some way to have"optional" return values, stabbing at a possible syntax to make the case:</div><div><br></div><div>Original:</div><div><br></div><div>def fun():</div><div>    return 5</div><div><br></div><div>called as:</div><div><br></div><div>x = fun()</div><div><br></div><div>Updated:</div><div><br></div><div>def fun()</div><div>    return 5, *, 6</div><div><br></div><div>Now it can still be called as:</div><div><br></div><div>x = fun()</div><div><br></div><div>and result in x == 5</div><div><br></div><div>or:</div><div><br></div><div>x, y = fun()</div><div><br></div><div>and result in x == 5, y == 6</div><div><br></div></div><div>So: syntax asside, I'm not sure how this could be implemented -- As I understand it, functions return either a single value, or a tuple of values -- there is nothing special about how assignment is happening when a function is called. That is:</div><div><br></div><div>result = fun()</div><div>x = result</div><div><br></div><div>is exactly the same as:</div><div><br></div><div>x = fun()</div><div><br></div><div>So to impliment this idea, functions would have to return an object that would act like a single object when assigned to a single name:</div><div><br></div><div>x = fun()</div><div><br></div><div>but an unpackable object when assigned to multiple names:</div><div><br></div><div>x, y = fun()</div><div><br></div><div>but then, if you had this function:</div><div><br></div><div>def fun()</div><div>    return x, *, y</div><div><br></div><div>and you called it like so:</div><div><br></div><div>result = fun()</div><div>x, y = result</div><div><br></div><div>either x, y = result would fail, or result would be this "function return object", rather than the single value.</div><div><br></div><div>I can't think of any way to resolve that problem without really breaking the language.</div><div><br></div><div>-CHB</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 26, 2019 at 9:48 AM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Jan 26, 2019 at 12:01:55PM -0500, Wes Turner wrote:<br>
<br>
> Tuples are a dangerous (and classic, legacy) interface contract.<br>
<br>
What?<br>
<br>
<br>
-- <br>
Steve<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>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Christopher Barker, PhD<br><br> Python Language Consulting<br>  - Teaching<br>  - Scientific Software Development<br>  - Desktop GUI and Web Development<br>  - wxPython, numpy, scipy, Cython<br></div>