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