[Python-ideas] kwargs for return

[Steven D'Aprano]

On Sat, Jan 26, 2019 at 03:29:59PM +0100, Anders Hovmöller wrote:
> 
> > I don't see anything here that can't be done by returning a dict, a 
> > namedtuple (possibly with optional fields), or some other object with 
> > named fields. They can be optional, they can have defaults, and you can 
> > extend the object by adding new fields without breaking backwards 
> > compatibility.
> 
> That assumes you knew before hand to do that. The question is about 
> the normal situation when you didn't.

Exactly the same can be said about the given scenario with or 
without this hypthetical "kwargs for return".

Thomas talks about having to change a bunch of backends. Okay, but he 
still has to change them to use "kwargs for return" because they're not 
using them yet. So there is no difference here.

The point is, you can future-proof your API *right now*, today, without 
waiting for "kwargs for return" to be added to Python 3.8 or 3.9 or 
5000. Return a dict or some object with named fields. Then you can add 
new fields to the object in the future, without breaking backwards 
compatibility again, since callers that don't expect the new fields will 
simply ignore them.

Of course if we aren't doing that *yet* then doing so for the first time 
will be a breaking change. But that can be said about any time we change 
our mind about what we're doing, and do something different.
 
> Also you totally disregarded the call site where there is no way to do 
> a nice dict unpacking in python.

It wasn't clear to me that Thomas is talking about dict unpacking. It 
still isn't. He makes the analogy with passing keyword arguments to a 
function where they are collected in a **kwargs dict. That parameter 
isn't automatically unpacked, you get a dict. So I expect that "kwargs 
for return" should work the same way: it returns a dict. If you want to 
unpack it, you can unpack it yourself in anyway you see fit.

But perhaps you are correct, and Thomas actually is talking about dict 
unpacking and not "kwargs for return". But perhaps if he had spent more 
time demonstrating what he wanted to do with some pseudo-code, and less 
explaining why he wanted to do it, I might have found his intention 
more understandable.


> The tuple case is super special and 
> convenient but strictly worse than having properly named fields.

In what way is it worse, given that returning a namedtuple with named 
fields is backwards compatible with returning a regular tuple? We can 
have our cake and eat it too.

Unless the caller does a type-check, there is no difference. Sequence 
unpacking will still work, and namedtuples unlike regular tuples can 
support optional attributes.


> To me this question sounds like it's about dict unpacking with one 
> special case to keep backwards compatibility. This should be possible 
> with a simple dict subclass in some cases...

This is hardly the first time dict unpacking has been proposed. Each 
time, they flounder and go nowhere. What is this "simple dict 
subclass" that is going to solve the problem?

Perhaps you should start by telling us *precisely* what the problem is 
that your subclass will solve. Because I don't know what your idea of 
dict unpacking is, and how it compares or differs from previous times it 
has been proposed.

Are there any other languages which support dict unpacking? How does it 
work there?



-- 
Steve