I know this is going to get rejected, but I want to speak out the idea nevertheless:

I love kwargs and named arguments from the beginning (roughly 18 years now)

I guess you came across this several times before:

In the first version of the API one variable gets returned:

Example:


    status = backend.transmit_data()

But later you want to add something to the API.


For the input part of a method this is solved. You
can add an optional kwarg.

But for the output part of a method, there you can't change
the interface easily up to now.

Use case: you want to add an optional list of messages which
could get returned.

You want to change to

    status, messages = backend.transmit_data()

If you have 10 different backend implementations,
then you need to change all of them.

This is difficult, if the backends reside in different
repos and maybe you even don't own some of these repos.

Current draw-back: you need to change all of them at once.

Of course you could work around it be using this

   status_messages = backend.transmit_data()

And then do some fancy guessing if the variable contains
only the status or a tuple containing status and messages.

Some days ago I head the idea that kwargs for return would
help here.


This should handle both cases:

Case1: The old backend returns only the status, and the caller
wants both status and messages. Somehow the default
for messages needs to be defined. In my case it would
be the empty list.


Case2: The new backends returning the status
and messages. The old caller just gets the
status. The messages get discarded.

Above is the use case.

How could kwargs for return look like?

Maybe like this:

  .....

Sorry, I could not find a nice, clean and simple syntax
for this up to now.

Maybe someone else is more creative than I am.

What do you think about this?


Regards,
  Thomas Güttler


-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines