I was going to write exactly they're same idea Steven did. 

Right now you can simply design APIs to return dictionaries or, maybe better, namedtuples. Namedtuples are really nice since you can define new attributes when you upgrade an API without breaking any old coffee that used the prior attributes... Of course, you can only add more, not remove old ones, to assure compatibility. Unlike dictionaries, namedtuples cannot contain arbitrary "keywords" at runtime, which is either good or bad depending on your purposes.

Recently, dataclasses are also an option. They are cool, but I haven't yet had a reason to use them. They feel heavier than namedtuples though (as a programming construct, not talking about memory usage or speed or whatever).

On Sat, Jan 26, 2019, 8:52 AM Steven D'Aprano <steve@pearwood.info wrote:

On Sat, Jan 26, 2019 at 02:04:12PM +0100, Thomas Güttler Lists wrote:

> Example:
>
>     status = backend.transmit_data()
>
> But later you want to add something to the API.
[...]
> How could kwargs for return look like?

return {'status': True, 'messages': []}

Or perhaps better:

return ResultObject(status=True, messages=[])


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.




--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/