[Python-ideas] kwargs for return
steve at pearwood.info
Sat Jan 26 10:30:11 EST 2019
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
> 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
More information about the Python-ideas